Interroga i dati prima di una transazione di commit

La mia comprensione è che, in una finestra di MS SQL Server Management Studio, dopo aver eseguito una "inizia transazione" e apportato alcune modifiche come aggiungere dati a una tabella, è possibile eseguire una query su quella tabella e tali modifiche dalla stessa finestra fino a quando non si esegue una "commit transazione".

Esiste un modo per eseguire una query da un'altra fonte prima di eseguire la "transazione di commit"?

Specifico per il mio obiettivo attuale e per aggiungere un po 'di contesto. Faccio alcune query SQL da Excel Power Query. Mi piacerebbe davvero poter fare queste query prima della "transazione di commit" in modo da poter fare qualche analisi e capire se dovrei fare un rollback invece di un commit.

Sì, è possibile se si modifica il livello di isolamento della transazione per la sessione (è ciò che si chiama "finestra" in SSMS) che richiede i dati modificati. Spesso questa non è un'ottima idea, in quanto potresti ottenere risultati inaspettati . Considera attentamente gli effetti collaterali. Non ho idea se è possibile modificare il livello di isolamento delle transizioni in Excel Power Query.

Ad esempio, il seguente set di query inserisce alcuni dati e visualizza correttamente l'aggiornamento anche senza commit / rollback.

-- 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;

Nel frattempo, la seconda sessione esegue una selezione che non sembra fare nulla:

-- Session 2
-- This waits for uncommitted transaction
-- and returns results after 1st session commits/rollbacks
select * from Test;

Crea una terza sessione e modifica il suo livello di isolamento:

-- Session 3
set transaction isolation level read uncommitted;
-- This reads the inserted data from the 1st session, even before commit
select * from Test;

Per quanto riguarda le migliori pratiche, le transazioni dovrebbero essere le più brevi possibili e non attendere mai l'interazione dell'utente ; ogni volta che si esegue un tipo di dati o modifica dello schema all'interno di una transazione, questo blocca gli oggetti o le righe che sono stati toccati / modificati, il che fa attendere le richieste degli altri utenti. Questo è il turno in grado di creare effetti a catena che possono arrestare il server di database.

Nello scenario che stai descrivendo, ti consiglio invece di fare una copia dei dati per separare le tabelle "what-if" in cui è possibile apportare le modifiche e rivedere i risultati. Una volta soddisfatti dei risultati, utilizzare una transazione per unire nuovamente i dati di questa tabella nelle tabelle originali.