Сложный T-SQL-скрипт, выполняемый с помощью TADOQuery, запускает «Пошаговые операции с несколькими шагами OLE DB».

Question

У меня есть очень большой блок SQL, который я пытаюсь выполнить внутри Delphi, против базы данных Microsoft SQL. Я получаю это:

Multiple-step OLE DB operation generated errors. 
    Check each OLE DB status value, if available. No work was done. 

Сценарий имеет несколько SQL IF заявления с последующим BEGIN и END блоков с вызовами хранимых процедур, объявления переменных и EXEC внутри этого. Наконец, он возвращает некоторые из значений переменных на SELECT @Variable1 AsName1,@Variable2 AsName2....

Вышеупомянутая многоступенчатая ошибка возникает как исключение OLEException из ADO, а не из кода Delphi, и происходит после того, как все SQL-exec-хранимые процедуры произошли, и поэтому я подозреваю, что он запускает это исключение OLE, когда оно доходит до финальной стадии, которая SELECT @Variable1 AsName1,... возвращает несколько значений переменной для моей программы, чтобы увидеть их.

Я знаю об этом отставной/осуждается MS KB статьи, и это, к сожалению, не мой фактический вопрос:

http://support.microsoft.com/kb/269495 

Короче говоря, что KB статья говорит исправить ключ системного реестра и удалить «Упорство Info Security» от строка подключения. Это не моя проблема. Я задаю этот вопрос, потому что я нашел ответ уже, и я думаю, что кто-то, кто застрял здесь, может не захотеть потратить несколько часов на поиски потенциальных проблем, когда есть несколько, которые я нашел после поиска решений в течение нескольких часов. Любой, кто хочет добавить другой ответ с различными вариантами, в порядке, и я выберу ваш, если он будет воспроизводимым, и в случае необходимости я превращу его в Community Wiki, потому что может быть дюжина неясных причин для этого «набора записей ADO находится в плохом настроении и недовольна вашим исключением T-SQL.

Answer 1

Я нашел несколько потенциальных причин, перечисленных в различных источниках документации. В исходной статье KB в вопросе предлагается удалить «Persist Security Info» из моей строки соединения ADO, однако в автономном тесте в приложении только с TADOConnection и одним TADOQuery наличие или отсутствие Persist Security Info не повлияло, явно устанавливая True или False.

Что DID это исправить удалял эту CursorType заявление:

CursorType=ctKeyset

То, что я узнал, что двунаправленные ADO наборов данных хороши для SELECT * FROM TABLE в ADO, но не так хорошо для сложных сценариев SQL.

Answer 2

Потенциальный источник этой ошибки обновляет поле char с большим значением.

Пример: у формы есть поле редактирования с максимальным значением длины, равным 20 символам, а таблица базы данных Oracle имеет поле, определенное как char (10). Обновление с 10 символами (или меньше) будет работать нормально при обновлении с более чем 10 символами, приведет к ошибке «Несколько шагов ...» на ADOQuerry.UpdateBatch(). Вы также должны знать, что у CHAR всегда будет 20 символов. Рассмотрим значение обрезки в поле редактирования. CHAR ведет себя иначе, чем тип VARCHAR2.

Answer 3

Если у вас есть запрос с параметром, проверьте, что количество параметров в запросе совпадает со сценарием ...!