これが私の架空のプログラムが作る一連のイベントです...
しかし、ああ、いや！ステップ3の間に、このプログラムを実行しているマシンは文字通り爆発しました。同じデータベースにクエリを実行している他のマシンは、展開されたマシンがまだ機能していて、何かを実行していると見なします。
私がやりたいのは、接続が開かれたときですが、変更を加える前に、何らかの理由でこの接続を閉じる必要があることをサーバーに通知して、SQLを実行するように指示します。そうすれば、何か問題が発生した場合に、クロージングアップデートが実行されることを確信できます。
（答えを先取りするために、私はテーブル/レコードロックまたはトランザクションを探していません。ここではリソースクレームを実行していません。）
どうもありがとう、billpg。
何かが組み込まれているのかわからないので、特注のことをしなければならないと思います...
これは完全に架空のものであり、頭のてっぺんからまっすぐですが、次のようになります。
コメントや改善を歓迎します！
コメントを拡張します。一般的に、私はあなたがあなたのアプローチを再考するべきだと思います。すべてのデータベースアクセスコードは、接続を開き、クエリを実行してから、接続プールに依存している接続を閉じて、多くのデータベース接続を開く費用を軽減する必要があります。
動作する行が変更されるべきではない単一のSQLコマンドについて話している場合、それはトランザクション分離レベルで処理する必要がある問題です。そのためには、SQLServer2005以降のスナップショット分離レベルを調べることができます。
長時間実行されるトランザクションの一部である一連のクエリについて話している場合、それはより複雑であり、他の接続が続行できるかどうかを判断するために読み取るトランザクション状態のストレージを介して処理できます。この道を進むと、ユーザーに、もはや適用できない可能性のある長時間実行されているトランザクションをキャンセルできるツールを提供する必要があります。
それが可能であると仮定すると...これは、トランザクション中にクライアントマシンが爆発した場合にのみ役立ちます。また、誤検知のリスクがあります。ネットワークノイズが原因で、接続が数秒間切断される可能性があります。
私が採用するアプローチは、別のマシンでプロセスを開始し、最初のマシンに定期的にpingを実行して、それがまだオンラインであるかどうかを確認し、到達不能になった場合にアクションを実行することです。