Коллеги!

Прошу помощи.

1. Ситуация

Есть некий батч, в котором я выполняю некоторые проверки.

Перед каждой проверкой я делаю PRINT N, где N - номер проверки.

Если выполнять скрипт по Query Analizer'е, то все эти N возвращаются.

По идее, они должны были и в ADODB.Errors попасть, если код выполнять под Delphi. Но попадают не все. Первая точно попадает. Если дальше где-то вызвать RAISERROR, то и он попадет, но только первый RAISEERROR.

2. Вопрос.

Сталкивался ли кто-то с такой особенностью ADODB и что с этим делать?

Спасибо.

PS. Delphi 2007, MSSQL 2000, ADODB 2.8, WinXPSP3

PRINT это не ошибка, сообщение, ну или вернее ошибка (по исполнению) с низким приоритетом. показывается только при определенных условиях (серверный курсор).

> но только первый RAISEERROR.
после raise в дельфе тоже код не выполняется... ну без определенных условий.

> и что с этим делать?
смирится и учить и привыкать как оно работает по умолчанию или углубленное изучение ADO и переписывать много много кода. например грид нельзя в некоторых случаях использовать... не работает при условиях работы PRINT-а.

> Есть некий батч

заведи в этом батче переменную, куда пиши результаты своих проверок. Потом возвращай как out-параметр, например

1. RAISERROR не прекращает выполнение.

код


выводит


тогда как


выводит



Причем как в QA, так и в ADO

2. Тогда такой вопрос: почему QA показывает и несколько print'ов и несколько raiserror'ов?
а) Варианты ответов, т.к. QA работает через ODBC и там иной подход к обработке ошибок.
б) Свой вариант.

ЗЫ Гридом не пользуюсь. Пользуюсь только ADODB, когда-то импортировал с тех пор и пользуюсь.

> junglecat ©   (24.01.15 21:54) [2]
> > Есть некий батч
> заведи в этом батче переменную, куда пиши результаты своих
> проверок. Потом возвращай как out-параметр, например


Я сейчас поставил себе задачу раз и навсегда разобраться с темой: return, raiserror, rollback. В дельфи был простой топик в справке, который внятно разъяснял, как идет выполнение кода, как на него влияет goto, exit, try, finally, break, continue и т.д.

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

Т.е. как-бы уже больше вопрос не практический, а больше по изучению темы.

ЗЫ Всегда можно что-то вернуть select'ом. Это я понимаю.

> 1. RAISERROR не прекращает выполнение.
> ну или вернее ошибка (по исполнению) с низким приоритетом.
у тебя пример не эксепта, а фактически аналога PRINT
вот так проверь
raiserror('error', 16, 1)

> sniknik ©   (24.01.15 23:51) [5]
> > 1. RAISERROR не прекращает выполнение.
> > ну или вернее ошибка (по исполнению) с низким приоритетом.
> у тебя пример не эксепта, а фактически аналога PRINT
> вот так проверь
> raiserror('error', 16, 1)


Прекрасно! Мы подошли к вопросу, который я не понимаю.

Если код выполнить в QA:




то вывод будет




Если же под ADO, то будет просто исключение с текстом error и ничего не вернется. Для получения RS в ADODB я пользуюсь ADODB.Comman.Fetch - т.е. Fetch свалился по исключению, есно рез-т не вернет.

Но!


выполнился!

Т.е. raiserror не прерывает выполнение. Подозреваю, что ты не прав, что raiserror с severity 16 прерывает выполнение. Просто ошибки накапливаются и в конце батча, если есть 16, то генерится исключение. Думаю, что так.

Если вернуться к исходному вопросу, то по идее ADODB.Connection.Errors должны накапливать как PRINT'ы, так и RAISERROR'ы.
А по факту накапливают не верно.
Может сталкивался именно с таким поведением?
Или вообще методика возврата гнилая?

Ладно, наверное, вопрос снимаю. Надо еще подумать в связи с открывшимся пониманием новых моментов.

> Т.е. raiserror не прерывает выполнение.
странно... но может быть, может не помню.

> по идее ADODB.Connection.Errors должны накапливать как PRINT'ы, так и RAISERROR'ы.
они накапливаются, в зависимости он настроек, писал выше. + попробуй к полученному рекордсету применить NextRecordset.
может прерывается получение списка а не выполнение на сервере.

> sniknik ©   (25.01.15 00:19) [7]


Я решил применить народную мудрость - от добра добра не ищут.
Нехилый проект работал 15 лет, обрабатывал ошибки и все было ок.
Тут что-то взбрело усовершенствовать)))

Буду, как и раньше, считать все исключения из ADODB ошибками, причем одиночными, а не набором данных всяких сообщений.

Буду по-старинке. "Это у меня манера такая", как говорил Никулин в к/ф "Когда деревья были большими".

Всем спасибо!

begin try
 create table qwerty(col int)
 raiserror('error', 16, 1)
 insert qwerty values(1)
 select * from qwerty
end try
begin catch
 print 'error raised'
end catch

junglecat ©   (25.01.15 11:16) [9]
о, точно, при правильном коде все логично работает. а без try (ТимоховДА   (25.01.15 00:10) [6]) действительно не прерывает, проверил.