<offtop>
Я конечно полный лох в работе с серьёзными БД (типа круче Парадокса), но вот уже создалось стойкое впечатление, что не всё так гладко в датском королевстве ADO при работе с параметрами в runtime.
</offtop>

> но вот уже создалось стойкое впечатление
и кто это тебя так "впечатлил"?

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

sniknik ©   (08.09.08 23:42) [13]
> Однако все равно не работает.
в коде нет указания типа параметра, а говоришь что он pdOutput.
как знал, что врешь.

Я не вру. Я с самого начала задал persistent-свойства коллекции Parameters, добавив в нее в дизайнере два параметра руками: с именем NAME (pdInput) и ID (pdOutput).
Ты прочитал мой последний пост (kaif ©   (08.09.08 23:35) [12] ) ?
Там ведь я прямо говорю, что после добавления в пакет явного старта транзакции все заработало.

Но объяснения я пока не знаю.
Хотелось бы понять логику этого самого ADOCommand при работе с пакетом команд.

И еще: что за транзакция стартовала? Вложенная?
Где почитать про грамотную работу с транзакциями MSSQL конкретно применяя компоненты ADO Delphi ? Мои поиски пока не увенчались успехом, к сожалению. Может Anatoly Podgoretsky © что-то подскажет?

> sniknik ©   (09.09.08 01:46) [21]

Коля. Спорить почти не буду. Ибо
> Я конечно полный лох в работе с серьёзными БД (типа круче
> Парадокса).

Но при работе с Парадоксом через BDE у меня никогда проблем не было.
Но и  
> вот ведь бардак! ну, что хотят то и творят эти борландовцы!

А что ADO компоненты писали борландовцы?

> Германн  (09.09.2008 2:05:23)  [23]

А кто?

стойкое впечатление, что не всё так гладко в датском королевстве ADO при работе с параметрами в runtime.

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

> Я не вру.
от меня это выглядит по другому... ты даешь часть кода и про ту часть которую не даешь говоришь "там все нормально там я ставлю вот это", когда же после показываешь вторую часть, в которой типа проблем нет. первое что бросается в глаза ты НЕ ЗАДАЕШЬ тот параметр который говорил задаеш...
я не говорю что ты специально, но то что ты врешь очевидно. если бы не скрывал и дал обе половинки кода сразу то я бы сказал заблуждаешься, а так....

> Я с самого начала задал persistent-свойства коллекции Parameters, добавив в нее в дизайнере два параметра руками: с именем NAME (pdInput) и ID (pdOutput).
а запрос вносишь после... забавно, а если в запросе другие параметры используются что делать дельфе?
так получается что тебе все равно, толи сесть в автобус и поехать толи сначала поехать потом сесть в автобус... только первое это повседневность, а второе каскадерский трюк.  

> что после добавления в пакет явного старта транзакции все заработало.
есть 2 обьяснения, первое ну ты наверное понял уже - ты врешь.
второе, запрос вносимый совпал с тем что уже вбит в дизайне, при полном добуквенном совпадении очевидно и параметры теже, смысла переинициализировать их нет... вот они и остались с настроенными уже типами. (по аналогии с локальными переменными, тебе повезло и созданная переменная заняла туже память что при предыдушем вызове, и значит осталась инициализирована старым значением)
больше склоняюсь к первому объяснению... из-за вот этого - #13, с трудом представляю чтобы такой перенос строки мог быть внесен в десигне, т.е. побуквенного совпадения не предвидится... хотя есть вероятность конечно какихто преобразований до сравнений (ни проверять ни лесть в генофонд неохота, проше думать что ты вреш пока ты этого не опровергнеш(или нет, в первом случае ты подтвердил) показав и вторую часть кода...).  

Германн ©   (09.09.08 02:05) [23]
> Но при работе с Парадоксом через BDE у меня никогда проблем не было.
у меня и при работе с ADO проблем никогда не было, даже когда они реально были в компонентах (была пара известных и уже пофиксенных багов), а все почему? думаешь изза того, что я такой умный? хотелось бы, но нет. просто первым, что сделал это прочитал документацию. и главное не просто прочитал, а еще и следовал ей (просто чтение никому не помогает), ее рекомендациям (например использовать ADOQuery/... только для перехода с BDE, т.е. такого временного решения пока не изучишь основные (/быстрого перевода BDE программы на ADO, за счет ухудшения работы собственно программы). я не переходил, я изучал, поэтому сразу взялся за основные забыв про "BDE заглушки", а основные проблемы(те баги о которых выше) именно с ними и были).

(была пара известных и уже пофиксенных багов)

Там даже не баги, а урезанная реализация некоторых возможностей.
Например беседовал с разработчиками провайдера к ИБ (lcpi ib provider), когда возник трабл с блобами. ("произошла ошибка во время выполнения многофазной операции .....")
Сам провайдер поставляется в трех версиях. Мне отвечают: в адо экспресс (delphi) возможна работа только с первой версией, бла бла бла, и еще возьмите самый последний триал.
Беру, проверяю. А там все тоже самое. На ровном месте: insert into values + блоб параметры

> Я конечно полный лох в работе с серьёзными БД (типа круче
> Парадокса), но вот уже создалось стойкое впечатление, что
> не всё так гладко в датском королевстве ADO при работе с
> параметрами в runtime.

Вообще то так и есть, реализация параметров в ADO.VCL грешит множеством ошибок, решается переходом на более старшие версии Дельфи, что мне в свое время и пришлось вынужденно сделать. И я не уверен, что Борланд устранил все ошибки, просто требуемые мне свойства заработали в 2006, а я последовательно проверял версии от Д5 до Д2006 и это ошибки именно Борланда, а не самого АДО, они почему то решили, что [N]VARCHAR это FixedChar, а Автоинкримент это Integer и так еще с несколькими типами. А модуль АДОDB построен так, что даже при желании правкой генофонда не проблему не решить, модуль не перекомпилируется, а только делает вид.
В то же время для не параметров эти типы реализованы правильно, и рантайм задача тоже решения не имеет, как ни указывай явно тип, он все равно меняется на FixedChar и прочее.
Судя по некоторым другим признакам, не все ошибки этого рода устранены и в 2006

> kaif ©   (08.09.08 21:03)  
> SELECT :ID = @@IDENTITY
поясните. что это?

> CREATE PROCEDURE SP_INSERT_GOOD(@NAME VARCHAR(60))
CREATE PROCEDURE SP_INSERT_GOOD(@NAME VARCHAR(60), @ID INT OUTPUT) ?
+

> SELECT :ID = @@IDENTITY
SELECT @ID = SCOPE_IDENTITY()
если так?

Set NoCount On;
Insert into ... (...) Values (....);
Select Result=Scope_Identity();

Выполнять через TADODataSet.Open;
Брать результат либо через TADODataSet.Fields[0[ либо через обычный FieldByName

> Там даже не баги, а урезанная реализация некоторых возможностей.
имел в виду именно баги, например был баг при внесении запроса частями через ADOQuery.SQL.Add(), чего по логике ADO делать было нельзя т.к. при внесении запроса определяются какието параметры, и определяются они на стороне сервера куда передается запрос, часть же всегда неправильна... кстати именно поэтому нужно подключение при разработке, можно конечно и без него и руками все устанавливать, толко основные претензии по этому поводу как раз в том что оно чегото не делает, а вот то что программист должен обеспечить какието условия для этого, это игнорируется.

этот баг миновал меня т.к. я им изначально не пользовался, а в CommandText вносить запрос частями затруднительно..., и т.д.

Anatoly Podgoretsky ©   (09.09.08 10:27) [28]
> Вообще то так и есть ...
вообщето это новая информация, не тронутая обсуждением до этого момента, а вывод "там чтото не то"  сделан смотря на когото у кого проблемы т.к. он инструкцию не прочитал, хотя на самом деле это все работает.
это все чем то похоже на выражение (гдето слышал) "если пристально на когото смотреть, любого можно принять за шпиона", т.е. выдать желаемое за действительное.

можно кстати конкретнее, чем то что написано мешает(дает глюки) в работе? (то что в приведении типов допущены огрехи неудивительно, но может в этом есть смысл? например FixedChar передавать кудато проще чем реализовывать полноценный механизм передачи строк именно переменной длинны, и кстати ничуть не затратнее по памяти если вначале посылки стоит длинна и памяти выделяется строго под данные, то какое значение имеет то что тип прописан максимумом длинны?)

b z   (09.09.08 11:08) [29]
Ega23 ©   (09.09.08 11:22) [30]
блин люди! да вы читать то умеете? и читаете ли что до этого было? прежде чем выдавать образцы корявого кода.

> SELECT :ID = @@IDENTITY
поясните. что это?
это правильное присвоение значения Output параметру. то что у когото он не является Output хотя он говорит обратное. не показатель того что это не работает.

> блин люди! да вы читать то умеете? и читаете ли что до этого
> было? прежде чем выдавать образцы корявого кода.


А что я корявого выдал?

2 sniknik ©  

Странно.
Ты так настаиваешь на том, что я вру, что я уже стал рыться в глубинах подсознания, пытаясь отыскать мотив того, зачем мне тебе врать. Правда так и не нашел. Логичнее предположить, что это какие-то твои собственные проекции.

Ты видно не понял, что я ставлю некоторые эксперименты, прежде чем что-то юзать.

Мне проще было установить параметры для эксперимента руками в коллекцию, задать не только их direction, но даже и типы данных. Раз уж существует дизайнер. Я же не привожу ту часть кода, где у меня выполняется TADOCommand.Create, к примеру. И ты вроде бы не упрекаешь меня в том, что я сам компонент еще не создал, а чего-то от него уже хочу. Или ты не в курсе того, что чтобы пользоваться TADOCommand нужно сначала создать экземпляр этого класса?
Если ты по любому поводу готов упрекать человека во вранье, я впредь конкретно для тебя буду приводить код, специально переписанный для тебя  в форме типа:

 MyCommand = TADOCommans.Create(nil)
 try
   MyCommand.Connection := ...
   и так далее, включая добавление параметров и всего такого
   MyCommand.Execute;
 finally
   MyCommand.Free;
 end

Но я всего этого делать не буду.
Так как после таких вот перлов

имел в виду именно баги, например был баг при внесении запроса частями через ADOQuery.SQL.Add(),

я просто понял, что ты не очень понимаешь, в какой последовательности в VCL работают элементарные вещи, например, что такое тип TStrings, в какой момент осуществляется парсинг текста запроса, как создается сама коллекция Parameters и кем именно.

Если бы ты это все понимал, то заметил бы, что у меня нет проблемы с тем, что параметр не найден (метод ParamByName вернул nil). И нет проблемы с тем, что в него что-то не записывается из-за "неопределенности direction", так как при наличиии одной команды в пакете (SELECT :ID = @@Error) прекрасно записывается. И дело здесь именно в том, что я прошу выполниться пакету команд, а не отдельно взятой команде. Так как с пакетами MSSQL я работаю впервые я хотел услышать мнение опытных людей. Точнее даже не мнение, а хотя бы ссылку на литературу с примером использования ADO Delphi конкретно в этом случае.

Что же я услышал от тебя кроме упреков в том что я вру?
Да ничего дельного в данном случае не услышал.
Впрочем, я ничего и не требовал.
Странно, видно тебе кажется, что ты мне обязан отвечать на мои вопросы, будто я тебя к чему-то принуждаю или чем-то задеваю. Иначе ты был бы выжливее и не стал бы обсуждать мою персону вместо того чтобы осбуждать проблему, которая почему-то таинственным образом решается при помощи BEGIN TRAN.

Надеюсь не обидел.

Ega23 ©   (09.09.08 11:22) [30]
Set NoCount On;
Insert into ... (...) Values (....);
Select Result=Scope_Identity();

Выполнять через TADODataSet.Open;
Брать результат либо через TADODataSet.Fields[0[ либо через обычный FieldByName

Спасибо. Похоже, то решение, что я сразу применил, т.е. вызов хранимой процедуры и получение выходного рекордсета (одной строки и одной колонки) методом Open, не является таким уж нетрадиционным решением проблемы.

Собственно, сейчас меня волнуют только транзакции. Когда я открываю набор, надо полагать, что стартует некоторая транзакция. С ADO я мало работал. С MSSQL через ADO не работал никогда.
Дайте ссылку, если у кого есть, на статью, где описано явное управление транзакциями MSSQL при помощи ADO Delphi.

> Похоже, то решение, что я сразу применил, т.е. вызов хранимой
> процедуры и получение выходного рекордсета (одной строки
> и одной колонки) методом Open, не является таким уж нетрадиционным
> решением проблемы.


Ну я ОЧЕНЬ часто именно так и делаю.

2 Ega23 ©   (09.09.08 13:04) [35]
Спасибо. Так работает.
И с 'Set NoCount On' и без него.
Кстати, по справке BOL я не могу понять какую область действия имеет эта команда. В пределах транзакции, сессии или как? И нужно ли после такого вызова делать Set NoCount Off? Или достаточно проделать один раз после открытия соединения и забыть об этом? Пользуются ли ADO информацией о количестве затронутых записей и не нарушит ли это все работу в каких-то других местах?

> sniknik  (09.09.2008 11:42:31)  [31]

> можно кстати конкретнее, чем то что написано мешает(дает глюки) в работе?

FixedChar <> NVarChar(WideString) = Char
Дело не в фиксированой длине, а то что теряется Юникод, да и сам FixedChar очень неприятен при использование в dbAware - что бы добавить в конец приходится сначала стереть кучу пробелов.

AutoInc <> Integer, хотя бы потому что он ReadOnly и не только Integer

Это не единственные ошибки с типам в параметрах, про остальные просто не помню, но когда разбирался - то помнил, и это по разному в Д5-2006 - похоже хвост отрубали по кускам.

> Кстати, по справке BOL я не могу понять какую область действия
> имеет эта команда. В пределах транзакции, сессии или как?
>  И нужно ли после такого вызова делать Set NoCount Off?
> Или достаточно проделать один раз после открытия соединения
> и забыть об этом? Пользуются ли ADO информацией о количестве
> затронутых записей и не нарушит ли это все работу в каких-
> то других местах?





Попробуй в QueryAnalyzer выполнить с Set NoCount On и без него.

Потом так попробуй:

> kaif  (09.09.2008 13:03:34)  [34]

Транзакции!
Их две

1. средствами Дельфи на стороне клиента, это когда транзакция запускается через TAdoConnection

2. транзакция запускается средствами сервера, через управление транзакцией в запросе BEGIN TRAN

Считается, что надежнее и правильнее вариант 2, но я всегда использую 1

По поводу литературы по ADO.VCL особо читать нечего, поскольку это всего лишь обертка над ADO (ActiveX) и вот это и надо читать, только тогда можно понять кухню и даже напрямую работать с АДО с помощью компонент. У Борланда много проблем в реализации обертки и конечно эти проблемы не документированы, можно конечно поискать проблемы в QC но стоит ли, это еще та помойка.

Кстати если нет особых условий, то TAdoCommand не требуется, поскольку запросы можно писать в TAdoConnection, можно даже и SELECT запросы и потом работать с _recordSet или переводить его в Dataset - но это уже лишнии сложности, на которые стоит идти только в особых случаях.