Se hai un blocco TRY/CATCH, la causa probabile è che stai rilevando un'eccezione di interruzione della transazione e continua. Nel blocco CATCH devi sempre controllare XACT_STATE()
e gestire le appropriate transazioni abortite e non vincolanti (condannate). Se il chiamante avvia una transazione e il destinatario raggiunge, ad esempio, un deadlock (che ha interrotto la transazione), in che modo il chiamato comunicherà al chiamante che la transazione è stata interrotta e non dovrebbe continuare con "business as usual"? L'unico modo possibile è sollevare nuovamente un'eccezione, costringendo il chiamante a gestire la situazione. Se ingoi silenziosamente una transazione interrotta e il chiamante continua a presumere che sia ancora nella transazione originale, solo il caos può assicurarlo (e l'errore che ottieni è il modo in cui il motore cerca di proteggersi).
Ti consiglio di esaminare Gestione delle eccezioni e transazioni nidificate che mostra uno schema che può essere utilizzato con transazioni nidificate ed eccezioni:
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
