Se você tiver um bloco TRY/CATCH, a causa provável é que você está capturando uma exceção de aborto de transação e continua. No bloco CATCH você deve sempre verificar o
XACT_STATE()
e lidar com transações abortadas e não confirmáveis (condenadas) apropriadas. Se o chamador iniciar uma transação e o receptor atingir, digamos, um impasse (que abortou a transação), como o chamador comunicará ao chamador que a transação foi abortada e não deve continuar com 'negócios como de costume'? A única maneira viável é re-aumentar uma exceção, forçando o chamador a lidar com a situação. Se você engolir silenciosamente uma transação abortada e o chamador continuar assumindo que ainda está na transação original, apenas o caos pode garantir (e o erro que você obtém é a maneira como o mecanismo tenta se proteger). Eu recomendo que você consulte Tratamento de exceções e transações aninhadas que mostra um padrão que pode ser usado com transações e exceções aninhadas:
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
