私の理解では、MS SQL Server Management Studioウィンドウで、「トランザクションの開始」を実行してから、データをテーブルに追加するなどの変更を行った後は、そのテーブルとそれらの変更を同じウィンドウからのみ実行できます。 「トランザクションをコミットする」。
「トランザクションのコミット」を行う前に別のソースからクエリを実行する方法はありますか？
私の現在の目標に固有で、いくつかのコンテキストを追加します。Excel Power QueryからいくつかのSQLクエリを実行します。「コミットトランザクション」の前にこれらのクエリを実行して、コミットの代わりにロールバックを実行する必要があるかどうかを分析して理解できるようにしたいと思います。
回答:
はい、変更されたデータをクエリするセッションのトランザクション分離レベル（SSMSでは "ウィンドウ"と呼ばれます）を変更することは可能です。予期しない結果が生じる可能性があるため、これはそれほど優れたアイデアではありません。副作用を注意深く検討してください。Excel Power Queryでトランザクション分離レベルを変更できるかどうかはわかりません。
たとえば、次の一連のクエリは、データを挿入し、コミット/ロールバックがなくても更新を正しく表示します。
-- Session 1
begin tran tx_test;
-- Assume the Test table exists and insert is okay
insert dbo.Test(datadate, content) values (getdate(), 'transaction');
select * from Test; -- Shows the new data
-- After select, one would execute one of the following
-- commit;
-- rollback;一方、2番目のセッションは何もしないように見える選択を実行します。
-- Session 2
-- This waits for uncommitted transaction
-- and returns results after 1st session commits/rollbacks
select * from Test;3番目のセッションを作成し、その分離レベルを変更します。
-- Session 3
set transaction isolation level read uncommitted;
-- This reads the inserted data from the 1st session, even before commit
select * from Test;ベストプラクティスの問題として、トランザクションはできるだけ短くし、ユーザーの操作を待たないようにする必要があります。トランザクション内で何らかのタイプのデータまたはスキーマの変更を実行するたびに、これにより、変更または変更されたオブジェクトまたは行がロックされ、他のユーザーのクエリが待機し続けます。これは、データベースサーバーを停止させる連鎖効果を生み出す可能性があります。
あなたが説明しているシナリオでは、代わりに、データのコピーを作成して、変更を加えて結果を確認できる「what-if」テーブルを分離することをお勧めします。結果に満足したら、トランザクションを使用して、このテーブルのデータを元のテーブルにマージします。