Jeśli masz blok TRY/CATCH, prawdopodobną przyczyną jest przechwycenie wyjątku przerwania transakcji i kontynuowanie. W bloku CATCH należy zawsze sprawdzić XACT_STATE()
i obsłużyć odpowiednie przerwane i niemożliwe do zatwierdzenia (skazane) transakcje. Jeśli dzwoniący rozpocznie transakcję i na przykład dojdzie do impasu (co przerwało transakcję), w jaki sposób osoba wywoływana zakomunikuje dzwoniącemu, że transakcja została przerwana i nie powinna kontynuować „działalności jak zwykle”? Jedynym możliwym sposobem jest ponowne zgłoszenie wyjątku, zmuszając wywołującego do poradzenia sobie z sytuacją. Jeśli po cichu połkniesz przerwaną transakcję, a dzwoniący będzie nadal zakładając, że nadal jest w oryginalnej transakcji, tylko chaos może to zapewnić (a błąd, który otrzymujesz, to sposób, w jaki silnik próbuje się zabezpieczyć).
Polecam zapoznać się z Obsługą wyjątków i zagnieżdżonymi transakcjami który pokazuje wzorzec, który może być używany z zagnieżdżonymi transakcjami i wyjątkami:
create procedure [usp_my_procedure_name]
as
begin
set nocount on;
declare @trancount int;
set @trancount = @@trancount;
begin try
if @trancount = 0
begin transaction
else
save transaction usp_my_procedure_name;
-- Do the actual work here
lbexit:
if @trancount = 0
commit;
end try
begin catch
declare @error int, @message varchar(4000), @xstate int;
select @error = ERROR_NUMBER(), @message = ERROR_MESSAGE(), @xstate = XACT_STATE();
if @xstate = -1
rollback;
if @xstate = 1 and @trancount = 0
rollback
if @xstate = 1 and @trancount > 0
rollback transaction usp_my_procedure_name;
raiserror ('usp_my_procedure_name: %d: %s', 16, 1, @error, @message) ;
end catch
end
go
