EXECUTE 後のトランザクション数は、BEGIN ステートメントと COMMIT ステートメントの数が一致していないことを示しています。前のカウント =1、現在のカウント =0

TRY/CATCH ブロックがある場合、考えられる原因は、トランザクションアボート例外をキャッチして続行することです。 CATCH ブロックでは、常に XACT_STATE() 中止された、コミット不可能な (運命にある) トランザクションを適切に処理します。呼び出し元がトランザクションを開始し、呼び出し先がデッドロック (トランザクションを中止した) にヒットした場合、呼び出し先は呼び出し元に、トランザクションが中止されたことをどのように伝え、「通常どおりのビジネス」を続けるべきではないのでしょうか?実行可能な唯一の方法は、例外を再発生させて、呼び出し元に状況の処理を強制することです。中止されたトランザクションを静かに飲み込み、発信者が元のトランザクションにまだあると想定し続ける場合、騒乱だけが保証できます (そして、エンジンがそれ自体を保護しようとする方法でエラーが発生します)。

 
 例外処理とネストされたトランザクション これは、ネストされたトランザクションと例外で使用できるパターンを示しています:
 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