Похоже уже глаз замылился.

Есть MSSQL, работаю через ODBC (так надо).
Есть таблица

Есть некий класс TDBConnector с методом




т.е. приняли на вход ADOCommand, проверили состояние коннекта, исполнили команду, отцепили от неё коннекшн.

Бросаю на форму TADOCommand.
выставляю в дизайн-тайм ParamCheck=False; CommandText = insert into testtbl (uid) values (:uid)
Ручками в дизайн-тайм добавляю параметр uid, выставляю Direction, DataType и Size.

В ран-тайм выполняю код:



всё ОК.

Добавляю в начало метода строчку
ADOCommand1.Parameters.Clear;
Всё ОК.

А вот теперь беру и делаю так:
В дизайн-тайм кладу чистый TADOCommand, не выставляю ему никаких свойств.

Код метода:




Выполняю, на Execute вижу ошибку Incorrect syntax near ':'
В профайлере на сервер запрос долетает в виде 'insert into testtbl (uid) values (:uid)'

Что не так делаю?

Непонятно зачем ты вообще устраиваешь пляски с бубном вокруг параметров - чем не устроила стандартная схема ?
Ну и чисто "профилактика": не стОит обзывать параметры именами, совпадающими с именами полей - достаточно вставлять какой-нибудь префикс (я использую буковку "р")

Грубо говоря, если ParamCheck=False, то добавление параметров отдано на откуп программиста. Что ты и делаешь.
Если же ParamCheck=True, то коллекция параметров генерится автоматом, и добавление их "руками" ни смысла, ни ожидаемого эффекта не имеет...

ЗЫ
Сабж надо рассматривать чисто с позиции академического интереса. Ибо автомат - наше всё :)

> Непонятно зачем ты вообще устраиваешь пляски с бубном вокруг
> параметров - чем не устроила стандартная схема ?


Тем, что у меня вообще не оконное приложение. И в дизайн-тайме я ничего выставить не могу.


> Если же ParamCheck=True, то коллекция параметров генерится
> автоматом, и добавление их "руками" ни смысла, ни ожидаемого
> эффекта не имеет...


Это только в том случае, если есть коннект. Если коннекта нет - один фиг ручками.

Нет, вы мне объясните: если я CommandText прописываю 'insert into testtbl (uid) values (10)'; - всё ОК.

Как только я задаю CommandText в ран-тайм и создаю параметр - всё, incorrect syntax

Блин, ну где же Коля?  :)

страно все это.
я просто создаю адокомманд, присваиваю текст в котором :параметры
затем Parameters.ParamValues[''] := бла бла бла
и все.

> страно все это.


Да у меня у самого уже башня едет. Как только ParamCheck=True - всё нормально проходит. Как только снимаю - всё, приехали.

а ADOCommand1.Prepared := true не надо сделать во 2-м случае?

> Выполняю, на Execute вижу ошибку Incorrect syntax near ':'
Ю В профайлере на сервер запрос долетает в виде 'insert into testtbl (uid) values (:uid)'

> Что не так делаю?
создаешь параметр сам, а синтаксис  оставляешь дельфевый (вот если бы ты пользовался дельфевым же препаре, тогда бы сработало (наверное... теоретически))

так должно сработать.

> так должно сработать.
не уверен, тк пользуюсь немного другой формой записи для таких случаев, попроще

В ADO компонентах Delphi при работе с MSSQL есть проблемы, с которыми я недавно столкнулся. Первая из них и состояла в странной работе парсера, который с параметрами разбирается. Например, параметр, созданный в дизайн-тайм после присвоения текста команде теряет свой тип. То есть вместо того чтобы придерживаться списка определенных разработчиком (persistent) параметров и их типов (и ругаться при execute), парсер почему-то заново создает параметры на ходу, как умеет. Это совершенно  несандартное поведение компонентов, шокирующее разработчика.

 Другим шокирующим меня лично благим намерением ADO стала полная невозможность избавиться от навязчивой манеры поддерживать многотабличную вставку, когда я его об этом вовсе не прошу. Мне так и не удалось победить это явление. Смысл следующий. Имеется команда select, в которой связаны 2 таблицы. Например, справочник товаров и позиции накладной. Хочется получить вставку строки в накладную. Но так как никаких свойств вроде InsertSQL, IpdateSQL и DeleteSQL у ADODataSet нет,  он пытается все эти запросы сам как-то сгенерировать, в результате он, естественно, пытается вставлять данные не только в таблицу накладных, но и наименования товаров в справочник товаров, хотя они там уже присутствуют и защищены у меня уникальным ключом.

Никакие советы и способы лечить эту проблему не сработали. Если мне потребуется писать реальный проект под MSSQL, я предпочту компоненты прямого доступа, либо воспользуюсь услугами BDE.

> Блин, ну где же Коля?  :)
работаю, блин!

> Никакие советы и способы лечить эту проблему не сработали.
Unique Table советовали? проверял?

> я предпочту компоненты прямого доступа
все компоненты "прямого" доступа для MSSQL работают через OLEDB т.е. тоже ADO только без "обертки", т.е. если они что то могут, а ты на ADO нет, значит просто не разобрался. а они просто привели логику ADO к твоей...

комнепонты прямого доступа работают через адо конечно, но именно через адо, а не через делфийское недоразумение вокруг него.

>kaif ©   (03.10.08 17:37) [9]
> Другим шокирующим меня лично благим намерением ADO стала полная >невозможность избавиться от навязчивой манеры поддерживать >многотабличную вставку, когда я его об этом вовсе не прошу.

Тебе же, Ашот, ясно было сказано в той ветке, что есть такая фигня, но ты, как тот ёжик, упорно лезешь на кактус..

>Ega23 ©   (03.10.08 15:35) [3]
>Тем, что у меня вообще не оконное приложение.

Причем тут вообще окна-то ?

sniknik ©   (03.10.08 17:40) [11]
> Никакие советы и способы лечить эту проблему не сработали.
Unique Table советовали? проверял?

Проверял.

Не вижу, какое отношение имеет OLEDB к проблемам того, что компонент ADO ведет себя нестандартным образом, например, тихаря переопределяет persistent свойства рантайм и не предупреждает об этом в документации. Это то же самое, что заявить, что раз глюкавый оконнный компонент использует нормально работающее в других компонентах API Windows, то значит, что я в нем плохо разобрался,  а не компонент глюкавый. На то он и компонент, чтобы вести себя стандартным образом. Для меня компоент это не просто класс - наследник TComponent. Для меня компонент это прежде всего контракт между разработчиком компонента и мной. Контракт, в котором любое нестандартное поведение обязано быть специально оговорено в Help.

Против самого OLEDB ничего не имею.

Как, впрочем, и против компонентов ADO Delphi в иных использованиях.
Я сам использовал палитру ADO достаточно часто при работе с dBase-файлами и файлами Access, и она меня там не подводила. Кроме одного случая, когда "благие намерения" ADO перекодировали файлы dBase, в заголовках которых ошибочно устанавливался байт кодировки (в FoxPro была такая проблема) и приходилось этот байт искусственно обнулять для того чтобы обойти эту угодливость ADO, плохо сочетавшуюся с либеральностью FoxPro  в отношении этого байта.

MsGuns ©   (04.10.08 02:00) [14]
>kaif ©   (03.10.08 17:37) [9]
> Другим шокирующим меня лично благим намерением ADO стала полная >невозможность избавиться от навязчивой манеры поддерживать >многотабличную вставку, когда я его об этом вовсе не прошу.

Тебе же, Ашот, ясно было сказано в той ветке, что есть такая фигня, но ты, как тот ёжик, упорно лезешь на кактус..

Если кто-нибудь приведет конкретное решение с Unique Table с примером работающего кода, буду признателен. Самому искать больше невмоготу и незачем. Может пригодится остальным участникам форума, решившим сделать ставку на связку ADO Delphi + MSSQL.

Любопытно, что работая с ADO.NET в Visual Studio на C# я не обнаружил вообще никаких проблем. Ничего такого непредвиденного.

О как... А если их (параметров) насколько, то

  ?

> О как...

Ага, именно так, как описано в справке...:)

Parameters[0], Parameters[1], можно присвоить имена параметрам.

> О как...
а ты как думал? :)
раз уж не пользуешься тем что дядя борланд написал, читай справку "оригинала".

> Если кто-нибудь приведет конкретное решение с Unique Table с примером работающего кода
я тут проверил... даже Unique Table не нужно (вернее нужно но не для этого), заявленная проблема "вставки куда не просят" -
> он пытается все эти запросы сам как-то сгенерировать, в результате он, естественно, пытается вставлять данные не только в таблицу накладных,
> но и наименования товаров в справочник товаров
вовсе и не проблема (вернее ADO/обертка к ней не причастны)... т.к. вставки не происходит если не редактировать значения второй связанной таблицы
т.е. пробовал запрос (отдаваемые на редактирование в грид поля выделены)


так вот если ввести значения всем полям, действительно идет вставка в обе таблицы (что естественно, раз ввели, или эти данные потеряются),
если же вводить только в поля первой таблицы т.е. - m.mInt,m.mName, вставки во вторую нет, даже без Unique Table.
т.е. получается что ты там где то задаешь значения второй таблице ("просишь о вставке данных"), а после удивляешься попытке сохранить эти данные...
> хотя они там уже присутствуют и защищены у меня уникальным ключом.
а вот тут уже нужна Unique Table, т.к. эти уже присутствующие данные необходимо отображать (?), типа ввели код товара в накладную и по нему "подтянулось" его значение из справочника, вот для такой "подтяжки" есть Resync Command, а она работает в паре с Unique Table (вот и ее необходимость, и потом без нее удаление будет происходить тоже обоих связанных записей).
но вообще это все есть в статьях на королевстве (блин вот почему их не было когда я это изучал?), ссылки куда тебе вроде давали (да и так найти не проблема).

> Parameters[0], Parameters[1], можно присвоить имена параметрам.
после того как создашь пожалуйста, а пока их нет... ошибка будет (вне списка).

2 sniknik ©   (04.10.08 12:34) [20]

То, что при update полей одной таблицы update вставки во вторую не происходит, это я и тогда обнаружил. Странно было бы, если бы это было не так. Собственно, а что вставлять?

Проблема совершенно в другом.

При вставке новой строки в набор,  а именно: строки, содержащей суррогатный id товара, наименование товара (исключительно лишь для того чтобы отобразить его в сетке) и его количество, то вставка произойдет в обе таблицы.

Мне неохота возвращаться к тем исследованиям. Вот куски кода, которые я закомментировал, пытался чего-то добиться. Результат был нулевым:

//  qryDetail.Properties['Unique Table'].Value := 'ORDER_ITEMS';
//  qryDetail.Properties['Update Criteria'].Value := adCriteriaUpdCols;
//  adCriteriaKey, adCriteriaAllCols, adCriteriaUpdCols

Сделаем проще. Вот примерно то, как я решаю подобную задачу в IBX (опустим лишнее, будем считать, что у нас всего одна накладная):

IBDataSet1.SelectSQL.Text = 'select n.id, g.good_id, g.name, n.quantity from goods g, nakl n where n.good_id = g.id';
IBDataSet1.ModifySQL.Text = 'update nakl set good_id = :good_id, quantity = :quantity where n.id = :old_id';
IBDataSet1.DeleteSQL.Text = 'delete from nakl where id = :old_id';
IBDataSet1.RefreshSQL.Text = 'select n.id, g.good_id, g.name, n.quantity from goods g, nakl n where n.good_id = g.id and n.id = :id';

То есть у меня имеется 4 команды. И полная свобода сделать именно то, что мне нужно, без недоразумений и гаданий. Единственное, чего мне не дает IBX - мультитабличной вставки. Ну и слава богу. К чему мне этот страшный сон?

И так вариантов поведения, которое разработчику может понадобиться  слишком много: и апдейты с использованием всех полей в WHERE, и апдейты с использованием только измененных, и апдейты с опорой на ключевые поля. И апдейты не всех измененных юзером в сетке полей, а лишь полей, указанных в SET ... = ..., не трогая иные поля. Да мало ли что захочет разработчик? Например в ModifySQL я вообще часто вписываю вызов хранимой процедуры.
Вот дали разработчику 4 команды и известно, что это именно те команды и только те команды, что отправятся на сервер. И ничего такого за кулисами, что бы за него додумывали.

И не только IBX Так устроены.

Впрочем, если Вам нравится то, как "ADO думает за нас", то, как говорится, на вкус и цвет... Тогда спор просто бессмысленен.

> исключительно лишь для того чтобы отобразить его в сетке
а ADO про это знает? что ты вставил в привязанную таблицу значения исключительно "на посмотреть".
про то и говорил ([20]), не надо туда писать, надо прописать код товара только основной таблице, и при записи сработает (если прописаны Resync Command, Unique Table) "подтяжка" значений ("суррогатный id товара, наименование товара") из дополнительной, для этой записи.
и все, только чуть чуть другая логика.  

> Впрочем, если Вам нравится то, как "ADO думает за нас", то, как говорится, на вкус и цвет...
какая разница нравится или нет? оно так есть, и все. хочешь пользоваться - изучай "механизм", как он работает. и следуй его логике. или пиши свою, но на основании этой уже существующей.
нравится логика с 4 отдельными запросами, что мешает добавить в ADO 4-ре ADOCommand и прописать в них такие же?
хочешь "все одном"? - сделай это компонентом.

> Тогда спор просто бессмысленен.
а кто спорит то?

sniknik ©   (04.10.08 14:45) [23]
нравится логика с 4 отдельными запросами, что мешает добавить в ADO 4-ре ADOCommand и прописать в них такие же?

А вообще это неплохая идея. Может и стоит реализовать как-нибудь свой TKaifADODataSet, прямого наследника TDataSet с 4-мя командами и парсером параметров, который не вызывается вторично, если коллекция параметров была создана дизайн-тайм.

И больше не иметь никаких проблем.

Дело все же я думаю не в иной логике. Я готов привыкнуть к иной логике. Например, логика работы самого MSSQL (например, триггеров и взаимодействия с ними внешних каскадных ключей) сильно отличается от логики IB Или ORACLE.
Но я заценил MSSQL, поработав с ним.
Это действительно весьма хороший и производительный сервер, и с ним приятно работать. И он мне быстро понравился, несмотря на иную логику почти во всем.
А вот реализация работы с ним через ADO-компоненнты в Delphi  нравилась мне все меньше и меньше, пока не разонравилась вовсе.

С уважением.

> Может и стоит реализовать как-нибудь свой TKaifADODataSet
наверняка уже такой есть, фанатов Fib-ов/пересаживающихся с IB, хватает, неужели мне первому это в голову пришло? вряд ли.

> А вот реализация работы с ним через ADO-компоненнты в Delphi
думаешь вот эта вот запись "не туда" реализована на уровне дельфевской обертки? ;) ... нет, это чисто ADO-шная вещь, сделай все на обьектах ADO, помучится тоже самое.

>kaif ©   (04.10.08 21:01) [24]
>А вообще это неплохая идея.

Это правильная идея - явно писать запросы на изменения в несколько таблиц, не полагаясь на "ителлект" оберток. А если уж полагаешься, то подстраивайся под них, а не пытайся бороться с ними. И не возмущайся на их "кривость", если они ведут себя "не так".

>И больше не иметь никаких проблем.

ИМХО, у тебя проблемы только потому, что ты сам их настойчиво выискиваешь

>Например, логика работы самого MSSQL (например, триггеров и >взаимодействия с ними внешних каскадных ключей) сильно отличается от >логики IB Или ORACLE.

В чем "сильность" ?

>Но я заценил MSSQL, поработав с ним.

Не ты один. Однако он весьма сложен в администрировании. В частности весьма трудно управлять логом (и вообще он, ИМХО, сделан совершенно идиотически, в связи с чем больше напоминает мусорную свалку, чем "журнал". Особенно когда надо в нем что-то найти).
Также неудобно реализованы копирования и восстановления. Нет возможности хранения скриптов и расширенных комментариев как в ИБ. Еще одна дурость - невозможность селекта из хранимок, а таже существенные ограничения при написания функций.
Еще мне не понравилось отсутствие такого удобного средства, как suspend, что приводит к тому, что сервер не начинает отсылку пока не выберет все. Иногда это приводит к излишней загрузке сети и ненужному ожиданию на клиенте.

Единственное СУЩЕСТВЕННОЕ отличие мсскл от ИБ - это абсолютно иной механизм транзакций. Вот к этому, действительно, надо приспособиться и привыкнуть.

>А вот реализация работы с ним через ADO-компоненнты в Delphi  нравилась мне все меньше и меньше, пока не разонравилась вовсе.

Что же касается ADO - то я не знаю другого такого же по гибкости и "комфортности" набора компонент. Во всяком случае по сравнению с IBX.

И последнее. Мне кажется, что многие из твоих проблем в связке ADO+MsSQL от "гридного" редактирования. Если ты сможешь заставить себя навсегда от него отказаться (имеется в виду не вообще от правки в сетках с т.зр.пользователя, а именно от редктирования самого датасета, "напрямую" связанного с таблицами БД), то проблем у тебя существенно поубавится.

MsGuns ©   (04.10.08 22:15) [26]
>Например, логика работы самого MSSQL (например, триггеров и >взаимодействия с ними внешних каскадных ключей) сильно отличается от >логики IB Или ORACLE.

В чем "сильность" ?

В том, что триггеры срабатывают после проверок на ссылочную целостность. И в том, что они все BEFORE. Плюс они срабатывают не на каждую запись, а на всю команду в целом. Например, IB при множественной вставке insert into ... select ... from ... сработает столько раз, сколько вставляется строк. А триггер MSSQL - единожды. На самом деле для задач, орудующих большими массивами это удобно.
Разумеется, отсутствие suspend меня сразу смутило. Но зато MSSQL позволяет очень лихо (и главное быстро, и это принятый прием) создавать временные таблицы внутри хранимых процедур и возвращать их набор.

Недостаток suspend восполняет функция, возвращающая тип данных TABLE. По крайней мере в MSSQL 2005 (а возможно и в 2000) это работает отменно, я попробовал.

Неприятным открытием для меня стало то, что если удаление строк делается в триггере, то каскадный внешний ключ просто не сработает. Здесь я вижу кривизну самой архитектуры - естественную плату за то, что триггер срабатывает единожды и срабатывает BEFORE.

Мне кажется, что многие из твоих проблем в связке ADO+MsSQL от "гридного" редактирования

Я не злоупотребляю гридным редактированием. Но считаю полный отказ от DATA AWARE компонентов другой крайностью. Нафиг тогда вообще это все было придумано? В IB у меня с этим проблем нет. Я же не вытягиваю таблицы на клиент в IBTable и не редактирую их там наивно в сетках.
Мне просто кажется естественным, когда юзер может в сетке подправить количества в нескольких строках накладной, содержащей в среднем 20 строк, не прибегая каждый раз к вызову диалогового окна для этой цели. Если есть проблемы с медленной отправкой строк на сервер в процессе такого редактирования (если честно, в IB таких проблем обычно просто нет), то можно использовать CachedUpdate := True и дело с концом - в ApplyUpdates я полностью управляю отсылкой данных так, как пожелаю.

Это ведь архитектура самого Delphi - работа с данными в Data Aware Controls. Я знаю людей, которые все запихивают в StringGrid только ради того чтобы не держать запрос открытым. Ну и зачем это? А если серверу все же нужно знать о необходимости блокировки? Я вижу, что в MSSQL Это весьма может быть актуальным.

sniknik ©   (04.10.08 21:38) [25]
> А вот реализация работы с ним через ADO-компоненнты в Delphi
думаешь вот эта вот запись "не туда" реализована на уровне дельфевской обертки? ;) ... нет, это чисто ADO-шная вещь, сделай все на обьектах ADO, помучится тоже самое.

Это я уже понял. Я сегодня внимательно рассмотрел модуль ADODB.PAS. :(
Но мне все же видится, что встроить 4 команды, как ты предложил, вполне реально. Наверняка можно заставить ADO не делать запрос "живым".

К сожалению в сети не так уж много литературы по ADO Delphi. И написано везде одно и то же. Ты говоришь о ссылках на статьи на Королевстве. Я тогда посмотрел все, что мне давали. Unique Table я так и не смог задействовать. Может быть времени не хватило. Но времени у меня и не было совершенно. И меня очень разражали проблемы на каждом шагу. Впрочем, это мои проблемы.

В пользу ADO (я работал через него с dBase и Access) могу сказать, что мне нравится его скорость Fetch-а, "гладкость" работы, экономность (как мне показалось) в отношении ресурсов и довольно развитая поддержка SQL в локальных вариантах (выборки из dBase). Например если бы не ADO, я бы вообще не знал как мне (иначе, чем разбирая dBase файл руками) считать двоичные данные из строковых полей (был такой раньше способ оптимального запихивания чисел в DBF). ADO позволил мне тогда получить эти данные в SELECT-е как cast(... as VarBinary()) или что-то в этом духе, может неверно помню, но работал такой typecast отлично. Никакие иные средства не позволяли (BDE, например) получить в строках символы после символа 0, так как они понимали 0 как конец строки (как и принято в Windows). А запиханные двоично числа в строки могли, разумеется, содержать нулевые байты. Поэтому я и говорю, что к OLEDB как таковому у меня особых нареканий нет.

А что, MSSQL не имеет разве своей клиентской dll ? А с чем же тогда BDE драйвер работает? Или он напрямую через TCP/IP  с сервером общается?

> А что, MSSQL не имеет разве своей клиентской dll
имеет конечно, прямо в виндовс встроенную (MDAC), но не в том виде что у IB/Firebird, не отдельная распространяемая вместе с программой, а устанавливаемый в винду пакет COM обьектов.

> А с чем же тогда BDE драйвер работает?
х.з. может с dblib, может что то своё, но строго говоря он уже давно не работает ... поддержка с версии MSSQL 6,5 прекращена.
только вариант с BDE + ODBC ещё "дышит", а  драйвера ODBC сейчас тоже входят в MDAC и не поймешь, кто там кого использует. вот для dbase/paradox очевидно, их драйвера ODBC используют jet (т.е. OLEDB провайдер.).

2 sniknik ©   (05.10.08 14:26) [28]
Спасибо за ответ.
Таким образом все "нативные" компоненты Delphi для MSSQL работают через COM-объекты MDAC, если я правильно понял.
Я бы предпочел, если честно использовать "нативные" компоненты (компоненты "прямого доступа"), а не ADO.
Какие конкретно (платные и бесплатные) существуют и какие из них кажутся Вам наиболее удачными?

<offtop>
Вот после таких веток и думаешь, почему все, кому не лень,  "столь грязно" ругают Парадокс?
</offtop>
:)

> и какие из них кажутся Вам наиболее удачными?
ни одни.
самые удачные, гибкие, и с максимумом возможностей (и потому самые сложные) это ADO.
было время тестировал парочку "прямого доступа", и ничего особого, кроме ограниченного функционала того же ADO в них не нашёл. другое дело работать с ними было попроще, реализована всего одна схема работы. но изучать/использовать их не рекомендовал бы, зачем изучать сурогат, когда есть оригинал? и нафига потом переучиваться, когда понадобится возможность которая есть в ADO, но которая проигнорирована в этих "найтивных"?

>Я бы предпочел, если честно использовать "нативные" компоненты (компоненты "прямого >доступа"), а не ADO.

Толкать грузовик вручную вместо того, чтобы просто запустить мотор и поехать ?

> > Непонятно зачем ты вообще устраиваешь пляски с бубном
> вокруг
> > параметров - чем не устроила стандартная схема ?
>
>
> Тем, что у меня вообще не оконное приложение. И в дизайн-
> тайме я ничего выставить не могу.

а добавить   Unit1 in 'Unit1.pas' {DataModule1: TDataModule};
и накидать чего хочешь?

Да, с ? вместо :param проблема решилась.
Всем спасибо, отдельно - sniknik ©

> kaif ©   (06.10.08 01:36) [29]


> Какие конкретно (платные и бесплатные) существуют и какие
> из них кажутся Вам наиболее удачными?


MSDAC

> kaif ©   (05.10.08 02:25) [27]

Я как то уже поднимал вопрос в форуме о некой урезанности функционала ADO по сравнению с тем же QA.
Получил ответ, что я не умею его готовить :)
Несмотря на применение всех советов, которые мне тут надавали, решить мою задачу удалось только прямым вызовом DBLib. И действительно, в ADO.Net таких проблем нету.

Короче, решений 3 :
1. Пользвать ADO с учетом граблей
2. Написать свои компоненты с использованием DBLib (я бы сказал - не простой способ)
3. Способ который выбрал я - перейти на оракл, для него есть весьма толковые нативные компоненты.

>  Вариант   (06.10.08 12:09) [35]

Дополню - http://devart.com/sdac/. есть и для других СУБД