Comportamento interessante in "NOEXEC ON"

Question

Mentre scrivevo alcune query T-SQL con NOEXEC ON, ho riscontrato un comportamento interessante di SQL Server e sono curioso di sapere perché è successo. A volte ho ottenuto solo

Comando (i) riuscito.

messaggio come mi aspettavo, ma a volte ho avuto uno o più

(0 row (s) affected)

messaggi.

so che SET NOEXEC ON comando compila interrogazione, ma non esegue esso, quindi penso che non dovrei ottenuto alcun

(0 row (s) affected)

messaggi.

Nel primo esempio, tutto sembra normale.

SET NOEXEC ON 
INSERT INTO Test (column1) VALUES ('etc') 

Risultato:

Command (s) con successo.

Ma nel secondo esempio, penso che qualcosa vada storto ...

SET NOEXEC ON 
DELETE FROM Test 

risultati:

(0 row (s) affected)

Nel terzo esempio ho usato tabella temporanea:

CREATE TABLE #tmp (id INT IDENTITY(1, 1), idX INT) 

SET NOEXEC ON 
INSERT INTO #tmp (idX) VALUES (1) 
DELETE FROM Test 

SET NOEXEC OFF 
DROP TABLE #tmp 

risultati:

(0 row (s) affected)

E infine ho aggiunto solo GO alla mia domanda, penso risultato è interessante

CREATE TABLE #tmp (id INT IDENTITY(1, 1), idX INT) 
SET NOEXEC ON 
GO 

INSERT INTO #tmp (idX) VALUES (1) 
DELETE FROM Test 

SET NOEXEC OFF 
DROP TABLE #tmp 

Risultato:

(0 fila (s) interessato)

(0 riga (e) interessata)

Answer 1

Anche se questo potrebbe non essere la risposta alla tua domanda:

Ma quando si elimina

SET NOEXEC ON 
DELETE FROM Test 

Se si aggiunge una condizione WHERE alla DELETE dichiarazione come DELETE FROM Test WHERE COLUMN1='etc'

Si otterrà il risultati desiderati ... Questo comportamento potrebbe essere dovuto alle dichiarazioni DDL e DML che abbiamo eseguito.

Ho anche analizzato la terza situazione in cui se inserisci nella tabella temporanea ti dà (0 righe interessate) ma se lo stesso inserto si trova su un database o una tabella permanente è fatto dà (Comando (i) completato con successo .)

Qui potrebbe essere a causa della tabella temporanea e della tabella permanente.

Per il 4 ° uno è stato aggiunto un GO:

GO eseguirà i relativi comandi SQL n volte.

Quindi, se si esegue singolarmente l'istruzione di inserimento e l'istruzione di cancellazione ha entrambi un valore di ritorno e GO li sta aggiungendo nel piano di lotti.

Answer 2

Riproduco il comportamento su SQl Server 2005 e 2008 quindi non è esclusivo per R2 e la stessa cosa accade con l'inserto, accade con la versione di aggiornamento, quindi l'eliminazione sembra essere l'eccezione.Anche Tronca (che è praticamente una cancellazione ottiene il messaggio standard)

Ho anche pensato che potesse essere una cosa di SQL Server Management Studio ma no, ho provato su un altro strumento e l'ho persino eseguito su SQLCMD e potevo vedere lo stesso comportamento :

Se non fosse che il "comando (s) con successo." messaggio non appare (questo deve essere esclusivamente di SSMS)

In ogni caso, non posso spiegare, ma posso indovinare. Immagino che accada perché l'istruzione delete fa qualcos'altro (o meno) che Insert e Update non fanno. Il processo di compilazione è diviso in quattro parti: analisi, normalizzazione, compilazione e ottimizzazione. Presumo che qualcosa all'interno di questi passaggi sia fatto in modo diverso dall'istruzione delete, ecco perché otteniamo un risultato diverso