Come accennato da Nick e Martin, l'eventuale stato della query dipende dal fatto che SQL Server sia a conoscenza del passaggio del cavo di rete prima del completamento della query. Da Books Online (anche se trovo interessante che ci siano argomenti equivalenti per questo nel 2000 , 2005 , 2008 e 2008 R2 , ma non nel 2012 o 2014):
Se un errore impedisce il corretto completamento di una transazione, SQL Server ripristina automaticamente la transazione e libera tutte le risorse trattenute dalla transazione. Se la connessione di rete del client a un'istanza del Motore di database viene interrotta, tutte le transazioni in sospeso per la connessione vengono ripristinate quando la rete notifica l'istanza dell'interruzione. Se l'applicazione client ha esito negativo o se il computer client si arresta o viene riavviato, anche questa interrompe la connessione e l'istanza del Motore di database ripristina eventuali connessioni in sospeso quando la rete lo avvisa dell'interruzione. Se il client si disconnette dall'applicazione, tutte le transazioni in sospeso vengono ripristinate.
(A parte questo, i collegamenti a parola nell'ultima frase erano probabilmente intesi come transazioni . Non so come si fa a ripristinare una connessione.)
In modo simile, SQL Server potrebbe annullare o ripetere le transazioni durante il ripristino dopo l'arresto imprevisto del server, e ciò dipenderà dallo stato della transazione al momento dell'arresto. Ho visto persone usare questa tattica per ottenere ciò che stavi cercando di fare (annullare la transazione) e quando il server è stato riavviato gran parte del lavoro è stato semplicemente rifatto (quindi l'effetto netto della loro reazione istintiva era molto più vicino a zero di quanto previsto).
Quindi piuttosto che essere soggetto a questo, invece di fare cose drastiche in preda al panico, come strappare un cavo di rete o spegnere la macchina, suggerisco in futuro di avere una migliore disciplina sull'esecuzione di query ad hoc contro sistemi importanti. Ad esempio, anziché:
UPDATE dbo.sometable
-- where *oops* I forgot this part
Avere questo:
BEGIN TRANSACTION;
UPDATE dbo.sometable
-- where *oops* I forgot this part
-- COMMIT TRANSACTION;
-- ROLLBACK TRANSACTION;
Quindi, se l'aggiornamento è stato effettivamente corretto, è possibile evidenziare la COMMITparte ed eseguirlo. In caso contrario, puoi evidenziare con calma la ROLLBACKparte ed eseguirla. Puoi anche utilizzare componenti aggiuntivi come SSMS Tools Pack per modificare il tuo New Querymodello per includere quella piastra di caldaia.
Ora potresti comunque metterti nei guai nel caso in cui eseguissi la query e non eseguissi il commit o il rollback, perché ora la tua transazione sta bloccando altri utenti. Ma è meglio quindi modificare irrevocabilmente i dati.
E ovviamente, come sempre, hai un backup su cui puoi contare.
