Имеется хранимая процедура, в которой выполняется команда INSERT, запускающая триггер FOR INSERT, который в свою очередь выполняет команду UPDATE. Выглядит это вот так (MS SQL 2000):
----------------------------
CREATE PROCEDURE spAddPlace (@sName varchar(50), @nTopid int) AS
BEGIN
declare @ErrorStatus int
SET NOCOUNT ON
SET LOCK_TIMEOUT 5000

BEGIN TRANSACTION

INSERT INTO tbPlace ( pname, topid ) VALUES ( @sName, @nTopid )
select @ErrorStatus = @@ERROR

if @ErrorStatus = 0 COMMIT TRANSACTION
else ROLLBACK TRANSACTION

RETURN (@ErrorStatus)
END
GO
----------------------------
CREATE TRIGGER tgAddPlace ON [dbo].[tbPlace]
FOR INSERT
AS
set nocount on
UPDATE tbPlace
SET subcount = P.subcount + (select count(*) from inserted where toppid = P.pid)
FROM tbPlace P, inserted I
WHERE I.toppid is not null
AND P.pid = I.toppid
----------------------------
Вобщем, в табличке хранится древовидная структура, и триггер просто добавляет количество "детей" у "родителя".
Теперь берем и выполняем в Query Analyzer'е следующее:

DECLARE @RC int
EXEC @RC = spAddPlace 'test', 123
select @RC

При отсутствии ошибок все проходит, и на выходе получаем 0. Однако, если в момент добавления "родитель" кем-то блокирован, то по истечении 5 секунд получим сообщение об ошибке номер 1222 "Lock request time out period exceeded. The statement has been terminated" и выполнение просто прерывается. Хотя, по идее, код этой ошибки должен сохраняться в переменной @ErrorStatus, дабы быть потом возвращенным из хранимой процедуры пользователю. Однако, этого не происходит. Все строки кода в процедуре после INSERT'а не выполняются, строка "select @@RC" после вызова процедуры тоже не выполняется. Если в триггере после UPDATE написать "print @@ERROR" - тоже не выполняется. Т.е., как будто происходит вылет вверх по всей цепочке вызовов. В чем причина? Помогите, пожалуйста, разобраться. Заранее спасибо.

Я тут поэкспериментировал, и вот что заметил. Получается, что дело не в LOCK_TIMEOUT, а в том, как ведет себя MS SQL 2000 (или триггер, или - не знаю кто ). Если в цепочке вызовов не присутствует триггер, то ошибка прекрасно ловится в текущем BATCH'е. Но если в эту цепочку вклинить триггер, в котором содержится команда, заведомо приводящая к ошибке на этапе выполнения (причем, любая ошибка, ну, например, INSERT в несуществующую таблицу заканчивается возвращением @@ERROR=208 ), то получаем все ту же картину: выполнение прерывается и ошибка не ловится, хотя Query Analyzer ругается. И, как сказал cvasil (которому, кстати, спасибо), "выставленная @@ERROR видна только в следующем батче текущего соединения". Т.е., если после неудачного завершения текущего BATCH'а сразу же посмотреть "select @@ERROR", она действительно-таки там присутствует, и можно произвести диагностику. Но ведь это уже в следующем батче. А можно ли поймать такую ошибку в текущем? И если можно, то как?

Вот сижу и не пойму: это что - очередной сюрприз Микрософта? Смотрю в BOL, раздел "Rollbacks in Stored Procedures and Triggers", а там написано:
--------------------------
You must use the SAVE TRANSACTION statement to do a partial rollback in a trigger, even if it is always called in autocommit mode. This is illustrated by the following trigger:

CREATE TRIGGER TestTrig ON TestTab FOR UPDATE AS
SAVE TRANSACTION MyName
INSERT INTO TestAudit SELECT * FROM inserted
IF (@@error <> 0)
BEGIN
ROLLBACK TRANSACTION MyName
END
--------------------------
Ну, случится этот самый ERROR в INSERT'е, и - большой привет, проверка никогда не выполнится. Хотя, с другой стороны, если люди пишут такую документацию, значит считают этот пример абсолютно рабочим? Значит, после генерации исключения в триггере его выполнение не должно прерываться? Почему ж тогда наблюдается противоположная картина? Может, есть все-таки методы? Может, установки какие-то или трюки?

Andreyka, Deem:
Ставил SET XACT_ABORT и ON и OFF - не помогает.
Andreyka:
Если бы все было так просто... Все дело как раз в том, что проверка "if @@ERROR >0" не отработает, если в "UPDATE" сгенерируется исключение. Прерывается выполнение всего пакета вплоть до верхнего уровня.

Я уже свел свои "изыскания" до минимума. Вот попробуйте сделать у себя такой примерчик, и посмотрите, что получается. Может, я действительно чего-то не вижу? (Напомню: это MS SQL 2000):
------------------------------------------------------------------------------
1. Создаем простенькую табличку Test с двумя полями - CODE int, NAME char(10).

2. Создаем триггер на вставку для этой таблички:
CREATE TRIGGER tgTest ON [dbo].[Test]
FOR INSERT
AS
set nocount on
insert into AbsentTable values (1,2,3) -- попытка вставки в несуществующую таблицу, стопроцентная ошибка
print 'Trigger: '+ltrim(str(@@ERROR))

3. В Query Analyzer'е пишем:
insert into Test values (1, 'Try insert')
select @@ERROR
------------------------------------------------------------------------------
Вот в такой ситуации я никогда не получу сообщения 'Trigger: 208' и не увижу результатов от "select @@ERROR". Хотя на закладке "Messages" появится ожидаемое сообщение об ошибке (и правильно, так и было задумано).
И все, батч прервался... Т.е., если даже и вставить проверку на наличие ошибки после INSERT (как в триггере, так и в Analyzer'е), она не отработает. А вот теперь, после того, как наш батч прервался, повторим в Query Analyzer'е "select @@ERROR" и увидим результат, с которым завершился предыдущий батч (т.е., 208 в данном случае). Но, опять же: это уже СЛЕДУЮЩИЙ батч, а поймать ошибку нужно было в текущем. Вот в чем вся загвоздка

Deem:
На клиенте в таком случае возникает EOleException, перехватив которое получаем:
1. В ErrorCode - сумасшедший отрицательный код (около 10 знаков), который абсолютно не является значением @@ERROR с SQL-сервера.
2. В Message - текстовое сообщение в оригинальном виде (естественно, на английском языке);

При всем при этом в @RETURN_VALUE хранимой процедуры возвращается 0, даже если перед вызовом проинициализировать его другим значением.

Deem:
Еще пока не написано. Только начинаю. Borland C++Builder 6. Вобщем-то, есть и 5-й, но если вышел 6-й - грех не попробовать

andreyka, Deem:
Похоже, докопался, наконец-то до того кода ошибки, который возвращается с сервера. Делаю вот что:
1. На сервере оставляю все, как и было.
2. На клиенте (BCB5,TADOConnection,TADOStoredProc) заключаю вызов хранимой процедуры в блок try...catch,
3. В catch'е смотрю в TADOConnection->Errors->Item[index]->NativeError. Вот там-то он и лежит - свеженький и нетронутый
(Item[index] - потому что в коллекции может присутствовать несколько ошибок, но в данном случае - всего одна)

А тот сумасшедший отрицательный код, который находится в ErrorCode объекта EOleException, лежит в TADOConnection->Errors->Item[index]->Number и, как пишет MSDN, "Indicates the number that uniquely identifies an Error object". В принципе, можно и им пользоваться, и, скорее всего, тоже не ошибешься, т.к., в том же MSDN говорится "Based on the error documentation from the Source, Number, and Description properties of Error objects, you can write code that will handle the error appropriately". Но, мне, например, гораздо больше по душе видеть первоисточник

Большое спасибо cvasil, andreyka, Deem! Всем - удачи!