И опять про обработку ошибок в хранимых процедурах :).\r
\r
Поискал по форуму\r
А как же транзакции???\r
Как обеспечить атомарность изменений в ХП???\r
Транзакции в хранимых процедурах\r
\r
Прочитал статейку Implementing Error Handling with Stored Procedures \r
\r
Хочется получить способ написания хранимых процедур в ASA9, в результате применения которого получаются процедуры, которые:\r
1. При ошибке откадываются до точки входа в процедуру или откатывают открытую транзакцию.\r
2. Произошедшая ошибка возвращается клиенту в исходном виде. То есть как если в "цивилизованном" языке сделать try .. except rollback raise end.\r
3. Текcт процедуры совместим с как можно бОльшим количеством других серверов, что означает\r
4. нужно использовать только Transact-SQL.\r
\r
Начал с BOL, плавно переходящий в google, что закончилось прочтением статьи Using transactions in stored procedures and triggers с сайта Sybase.\r
\r
В статье все очень хорошо описано. Из нее, в частности, следует что все вместе получить не удастся, что расстроило меня окончательно. А не удастся потому что другая статья с Sybase гласит, что\r
\r
Если процедура на Transact-SQL, то все зависит от опции ON_TSQL_ERROR :\r
\'STOP\' : ошибка летит на клиента, но тогда ничего не откатывается. Конечно, начатую в процедуре транзакцию можно откатывать на клиенте, но как-то коряво получается. Учили же - где ты объект создашь, там ты за собой и убери. Можно еще не начинать транзакцию в процедуре, а все делать с клиента, но это тоже как-то подозрительно.\r
\'CONTINUE\' : ошибку можно обработать, проверяя @@error, SQLSTATE и SQLCODE и делать все что душе угодно. Не дает покоя одна вещь - к моменту завершения строчки "SELECT @Error = @@error" ошибки уже не существует.\r
\r
То есть, если каждую строчку обрамлять в IF, то откатить все можно замечательно, но вот про возвращение исходной ошибки придется забыть.\r
\r
Также выяснил что SQLSTATE и SQLCODE - вещи очень хорошие, и если вовремя их запомнить то впоследствии можно получить текст сообщения для исходной ошибки. @@error в этом отношении убога - имеет пару десятков значений, и в большинстве случаев это -16 \'Other User Error\'. Очень содержательно :).\r
\r
Значит, код ошибки и сообщение получили. Как же их теперь на клинта запулить? Первом делом взгляд падает на RaisError, но оказывается что ей можно пулять только "пользовательские" ошибки, и при попытке запулить ошибку с кодом из SQLCODE на клиенте получаем "Error number for RaisError may not be less than 17000" :(.\r
\r
Вы спросите, зачем мне так нужен код ошибки? На клиенте хочется обрабатывать ошибки "в одном месте" :) и в зависимости от кода ошибки подгружать дополнительное объяснение для пользователя что произошло. Да и уютнее как-то когда ты ошибку не прячешь, а передаешь дальше по цепочке.\r
\r
Замечательную идею излагают в обсуждении Хороший тон в процедурах. Использовать триггер для выбрасывания ошибки, тем самым откатывая транзакцию. Только опять мы у разбитого корыта - тот же RaisError.\r
\r
Хорошо иметь на MSSQL опцию SET XACT_ABORT ON (которая, как я понял, тоже не для всего работает). Хорошо писать на watcom и иметь except и resignal (как я понял из описания, resignal работает как raise?).\r
\r
Но как же быть с ASA и Transact SQL?\r
\r
В общем, на пока решили возвращать SQLCODE как доп. параметр с условленным именем из каждой процедуры, и на клиенте обрабатывать в общем месте. При помощи доп. кода подогнать так, что ошибка "вручнцю" будет эквивалентна серверной ошибке. Ну и, соответственно, все хранимые процедуры "подкручивать" чтобы после вызова вложенной процедуры они бы проверяли не только SQLCODE, но и те самые условленные параметры.\r
\r
Но неужели нельзя чтобы и просто и работало как следует?\r
\r
Спасибо.

Дело в том, что в случае обработки ошибки в процедуре на клиента она уже не возвращается. По крайней мере не в первозданном виде, это точно.

Пробовал создать 3 разных "ошибочных" процедуры и запустить их прямо из isql. Опция Stop ON_TSQL_ERROR = 'CONDITIONAL'.
Все три делали return @error (которая набивалась из @@error).

Первая после ошибки ничего не делала, в результате чего возвращалось красивое сообщение со всеми кодами ошибок. Транзакция, понятное дело, не откатывалась.
Во второй обрабатывал ошибку, откатывая транзвкцию. В результате ошибка терялась и никаких сообщений не выскакивало.
Третья после отката делала RAISERROR. Получаемое сообщение имело уже мой код ошибки и мое сообщение.

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

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