2

私は .NET 2.0 と SQL Server 2005 を使用しています。歴史的な理由から、アプリ コードは SQLTransaction を使用していますが、一部のストアド プロシージャは T-SQL の begin/commit/rollback tran ステートメントも使用しています。DBTransaction は多くのストアド プロシージャにまたがることができ、個々の sproc がそのスコープ内で何が起こっているかを制御します。実際には、これらはネストされたトランザクションです。

コードの古い動作では、いずれかの sproc が失敗すると、アプリケーション ロジックによって外側の SQLTransaction もロールバックされます。しかし、ここでロジックを変更して、障害が発生した場合でも、外側のトランザクションが残りの sproc をそのシーケンスで実行し続け、最後に、障害があったことがわかっているので、SQLTransaction 全体をロールバックします。

問題は、少なくとも現在コーディングされているように、いずれかの sprocs が ROLLBACK を実行すると、外側の SQLTransaction が接続を失ったように見えるため、その後のトランザクションの再利用の試みが失敗することです。T-SQL でロールバックする方法はありますが、外部の SQLTransaction は維持できますか? ここでセーブポイントが役立つのではないかと思っていましたが、まだよくわかりません。

この状況を複雑にしているのは、外部トランザクションが常に存在するとは限らないため、T-SQL ロールバックを単純に削除できないことです。場合によっては、sproc が単独で実行されます。時にはトランザクションのコンテキストで。

TransactionScope に切り替えると作業が簡単になりますか?

提案をありがとう...マイク

4

3 に答える 3

0

IMPLICIT_TRANSACTIONを参照してください。基本的に、これを使用して、ストアド プロシージャのトランザクション依存モードを変更できます。多くの場合、これはより簡単な解決策です。

于 2008-12-26T06:23:10.403 に答える
0

TSQL 内ですべてのネストを維持できるように、外部トランザクションもストアド プロシージャに配置することを検討することをお勧めします (EXEC を使用して他のストアド プロシージャを呼び出します)。SQL Server は驚くほど豊富な開発/データ管理環境であり、ADO がぎこちなく処理する方法でトランザクションを管理できます。また、ほとんどの場合、ADO 接続を介して複数の呼び出しを行うよりも、一連の SQL をストアド プロシージャにまとめる方が効率的であることにも注意してください。

于 2008-12-23T23:55:08.877 に答える
0

次のナレッジベース エントリをご覧ください。

データ ソース エラーが発生した後にトランザクションがコミットまたはロールバックされると、予期しない例外が発生することがある

ストアド プロシージャ内でトランザクションをロールバックすると、ADO.NET クライアント内の「外部」トランザクションが消失します。唯一の解決策は、Rollback() 呼び出しを try/catch ブロックでラップすることです。それが起こった場合、外部トランザクションを維持することは不可能だと思います。

于 2008-12-23T23:44:50.507 に答える