6

現在のシステムのエラー処理を改善して、より意味のあるエラー メッセージを生成しようとしています。他のネストされたストアド プロシージャを複数回呼び出す "ルート" ストアド プロシージャがあります。

ルート sp ではXACT_ABORTに設定さONれますが、ネストされたプロシージャでXACT_ABORTは に設定されOFFます。ルート プロシージャのエラーを取得するのではなく、下位レベルのプロシージャから特定のエラーを取得したいと考えています。

よく見かけるエラーですが、uncommittable transaction is detected at the end of the batch, the transaction is being rolled back.

これらの「混合」環境を で使用することには影響がありXACT_ABORTsますか?

また、高度なエラー処理に関する提案があれば、それは大歓迎です。sp_executesqlすべてのストアド プロシージャを変更せずにパラメータを渡してエラー出力を取得しRAISERROR、親プロシージャのCATCHブロックを呼び出すために使用できるように使用したいと思います。

4

2 に答える 2

5

ここでのAndomarの回答とMSDNによると：

SET XACT_ABORT の設定は、解析時ではなく、実行時または実行時に設定されます。

つまり XACT_ABORT、作成セッションから各プロシージャに「コピー」されないため、このオプションを内部的に明示的に設定しない PROC は、実行時にアンビエント セッションから設定を継承し、悲惨な結果になる可能性があります。

FWIW、原則として、常にXACT_ABORTグローバルにオンになっていることを確認し、lint チェックを行って、どの PROC もこの設定をオーバーライドしていないことを確認します。

XACT_ABORTただし、特効薬ではないことに注意してください。たとえば、RAISERROR を使用して PROC によって発生したエラーは、バッチを終了しません。ただし、これはSQL 2012のTHROWキーワードで改善されているようです

あなたが提案したように、またRemus Rusanu の観察によると、構造化された例外処理 (TRY / CATCH) は、例外を処理するためのはるかにクリーンで堅牢なメカニズムです。

于 2012-11-09T11:05:29.673 に答える