Обработка ошибок в бизнес-логике приложения

AnS1
Дата: 01.11.2000 13:56:51
Ситуация:
бизнес-логика приложения построена на sp.
информирование клиента о попытках нарушить правила построено на использовании RaiseError по примеру:
проверка правила
если нарушено то
raiserror('Клиент нарушил правило...',16,1,1)
rollback tran
return
В полный рост применяются вложенные процедуры.
Клиент - приложение на VB с ADO 2.5

Проблемы:
1. В некоторых случаях клиент НЕ обрабатывает ошибки - в Query Anal ошибки видны. Как правило,
такое происходит, если ошибка возникает во вложенной sp.
2. На машине разработчика ошибки обрабатываются нормально, на машинах других пользователей - ошибка происходит,
транзакция откатывается, но ошибка не "отлавливается". Хотя, возможно, это зависит не от машин, а от системной
политики.

Вот так. Если кто что знает, сообщите в конференции или пишите anatolys@rambler.ru
Fompro
Дата: 01.11.2000 21:32:58
У Вас анализ в вызывающей процедуре на @@ERROR идёт?
AnS1
Дата: 02.11.2000 05:21:36
Нет. Бизнес-правила проверяются явно. Ссылочная целостность в данном случае не достаточно функциональна.
Fompro
Дата: 02.11.2000 19:08:48
Вы не могли бы выслать на мой Mail образцы вложенных пр-р (критичные участки) и скрипт их вызова и обработки?
Semen
Дата: 03.11.2000 08:04:09
Может этот и не правильно, но мы используем
raiserror('Невозможно удалить пользователя...',11,1)
и все работает. Именно 11,1.
Правда у нас Delphi через dblibrary.
Fompro
Дата: 03.11.2000 16:37:38
На последнее сообщение.
Да, конечно. Правда я сам предпочитаю 016 - Miscellaneous user error.
Если мне память не изменяет, в курсорах, использующих #table приходится использовать внесённый в sysmessages №. На клиенте у меня PowerBuider.
AnS1
Дата: 04.11.2000 06:47:06
Я разобрался. Уф.
В действительности, если процедура
возвращает данные, неважно, выборки, или кол-во строк,
ADO не отлавливает ошибку.
Если поставить в процедуре первого уровня nocount on и
избавиться от явных выборок (не присвоений типа select @qwe = qwe ...)
то все становится хорошо, ошибки отлавливаюся :)
Интересно было бы узнать интерпретацию данной ситуации
- это глюк или фича :)
Fompro
Дата: 07.11.2000 17:42:54
Скорее всего, ошибка ADO. Ниже я не лез. У меня была SP с кучкой UNION, которая из под РВ выполнялась в любом случае (что с NOCOUNT, что без), но это практически чистая DB-LIBRARY. Выполнение её из тестового примера из MSDN (ADOSimple - C++) не приводипо ни к каким результатам, до тех пор не был поставлен NOCOUNT.