私が持っているInsertにデータを送りますストアドプロシージャTable1とget Column1から値をTable1と表2を養う二ストアドプロシージャを呼び出すを。
しかし、2番目のストアドプロシージャを次のように呼び出すと、
Exec USPStoredProcName次のエラーが発生します。
EXECUTE後のトランザクション数は、BEGINステートメントとCOMMITステートメントの数が一致しないことを示しています。以前のカウント= 1、現在のカウント= 0。
私は他のそのような質問の答えを読みましたが、正確にコミット数がめちゃくちゃになっている場所を見つけることができません。
回答:
TRY / CATCHブロックがある場合、考えられる原因は、トランザクションアボート例外をキャッチして続行していることです。CATCHブロックでは、常にを確認しXACT_STATE()、適切に中止されコミットできない（終了した）トランザクションを処理する必要があります。呼び出し元がトランザクションを開始し、caleeが（トランザクションを中止した）デッドロックにヒットした場合、呼び出し先は、トランザクションが中止され、「通常どおりのビジネス」を続行すべきでないことを呼び出し元にどのように伝えますか？実行可能な唯一の方法は、例外を再度発生させ、呼び出し側に状況を処理させることです。中止されたトランザクションを黙って飲み込み、呼び出し元がまだ元のトランザクションにいると想定し続ける場合、確認できるのは騒乱だけです（そして、エラーは、エンジンがそれ自体を保護しようとする方法です）。
ネストされたトランザクションと例外で使用できるパターンを示す例外処理とネストされたトランザクションを検討することをお勧めします。
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
xact_abort onか、それとも使用していますか？
私もこの問題を抱えていました。私にとって、その理由は
return
commit
の代わりに
commit
return
1つのストアドプロシージャ。
これは通常、トランザクションが開始され、コミットされていないか、ロールバックされていない場合に発生します。
ストアドプロシージャでエラーが発生した場合、例外処理がないと、いくつかのランタイムエラーが原因でトランザクションが完了しないため、データベーステーブルがロックされる可能性があります。以下のような例外処理を使用できます。 SET XACT_ABORT
SET XACT_ABORT ON
SET NoCount ON
Begin Try
BEGIN TRANSACTION
//Insert ,update queries
COMMIT
End Try
Begin Catch
ROLLBACK
End Catch
ネストされたトランザクションを使用する場合、ROLLBACK操作は最も外側のトランザクションを含むすべてのネストされたトランザクションをロールバックすることに注意してください。
これをTRY / CATCHと組み合わせて使用すると、説明したエラーが発生する可能性があります。詳細はこちら。
これは、トランザクションを開いた後にストアドプロシージャでコンパイルエラーが発生した場合にも発生します（たとえば、テーブルが見つからない、列名が無効）。
私は2つのストアドプロシージャを使用する必要があることに気付きました。「ワーカー」と、Remus Rusanuによって概説されているものと同様のロジックを持つtry / catchを使用したラッパーです。ワーカーキャッチは「通常の」エラーを処理するために使用され、ラッパーキャッチはコンパイルエラーを処理するために使用されます。
https://msdn.microsoft.com/en-us/library/ms175976.aspx
TRY…CATCH構成の影響を受けないエラー
次のタイプのエラーは、TRY…CATCHコンストラクトと同じ実行レベルで発生した場合、CATCHブロックでは処理されません。
- 構文エラーなど、バッチの実行を妨げるコンパイルエラー。
- 名前解決の遅延のためにコンパイル後に発生するオブジェクト名解決エラーなど、ステートメントレベルの再コンパイル中に発生するエラー。
うまくいけば、これは誰かがデバッグの数時間を節約するのに役立ちます...
私の場合、エラーは内で発生してRETURNいましたBEGIN TRANSACTION。だから私はこのようなものを持っていました：
Begin Transaction
If (@something = 'foo')
Begin
--- do some stuff
Return
End
commitそしてそれはする必要があります：
Begin Transaction
If (@something = 'foo')
Begin
--- do some stuff
Rollback Transaction ----- THIS WAS MISSING
Return
End
commit同じエラーメッセージが表示されましたが、COMMIT TRANSACTION行の最後にセミコロンが付いていました
これは、C＃コードからSPを呼び出す方法にも依存します。SPがテーブルタイプの値を返す場合は、ExecuteStoreQueryを使用してSPを呼び出し、SPが値を返さない場合は、ExecuteStoreCommandを使用してSPを呼び出します。
使用を避ける
RETURN使用時のステートメント
BEGIN TRY
...
END TRY
BEGIN CATCH
...
END CATCHそして
BEGIN, COMMIT & ROLLBACKSQLストアドプロシージャのステートメント