2012-05-10 5 views
11

Während ich einige T-SQL-Abfragen mit NOEXEC ON schrieb, erlebte ich interessante Verhalten von SQL Server und ich bin neugierig, warum es passiert ist. Manchmal habe ich nurInteressantes Verhalten in "NOEXEC ON"

Befehl (e) erfolgreich.

Nachricht als ich erwartet habe, aber manchmal habe ich ein oder mehr

(0 Zeile (n) betroffen)

Nachrichten.

Ich weiß, dass SET NOEXEC ON Befehl kompiliert Abfrage sie aber nicht ausführen, so dass ich denke, dass ich keine

bekommen sollte

(0 Zeile (n) betroffen)

Nachrichten.

Im ersten Beispiel sieht alles normal aus.

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

Ergebnis:

Befehl (e) erfolgreich.

Aber im zweiten Beispiel denke ich, dass etwas schief geht ...

SET NOEXEC ON 
DELETE FROM Test 

Ergebnis:

(0 Zeile (n) betroffen)

Im dritten Beispiel I temp-Tabelle verwendet:

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 

Ergebnis:

(0 Zeile (n) betroffen)

Und fügte ich schließlich nur GO auf meine Frage, ich glaube Ergebnis

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 

Ergebnis ist interessant:

(0 Zeile (s) betroffen)

(0 Reihe (n) betroffen)

+0

Hm Ich kann keinen Fall repro wo ich bekomme "(0 Zeile (n) betroffen)". Weder in Denali noch in SQL Server 2008. Haben Sie diese SQL-Texte nur mit SSMS ohne spezielle Optionen oder Aktionen ausgeführt? – usr

+0

Ja, ich habe diese SQL-Texte mit SSMS unter SQL Server 2008 R2 ausgeführt und keine speziellen Optionen verwendet. – ogun

Antwort

2

Obwohl dies nicht die Antwort auf Ihre Frage:

Aber wenn man

SET NOEXEC ON 
DELETE FROM Test 

löschen Wenn Sie einen in dem Zustand an den DELETE STATEMENT wie DELETE FROM Test WHERE COLUMN1='etc'

hinzufügen, werden Sie das bekommen gewünschte Ergebnisse ... Dieses Verhalten kann auf DDL- und DML-Anweisungen zurückzuführen sein, die wir ausgeführt haben.

Ich habe auch die dritte Situation analysiert wo in, wenn Sie in temporäre Tabelle einfügen gibt es Ihnen (0 Zeilen betroffen), aber wenn die gleiche Einfügung ist in einer Datenbank oder permanente Tabelle ist es gibt (Befehl (e) erfolgreich abgeschlossen .)

Hier könnte es wegen der temporären Tabelle und der permanenten Tabelle sein.

Für das 4. von Ihnen hinzugefügt haben ein GO:

GO die entsprechenden SQL-Befehle n-mal ausführen wird.

Wenn Sie also die INSERT-Anweisung und die DELETE-Anweisung einzeln ausführen, hat beide einen Rückgabewert, und GO fügt sie im Stapelplan hinzu.

1

Ich reproduce das Verhalten auf SQl Server 2005 und 2008, so ist es nicht exklusiv für R2 und die gleiche Sache, die mit der Einfügung geschieht, geschieht mit der Update-Anweisung, so scheint zu löschen die Ausnahme zu sein.Sogar Trunkieren (das ist so ziemlich ein Löschen erhält die Standardnachricht)

Ich dachte auch, es könnte eine SQL Server Management Studio Sache sein, aber nein, ich testete auf einem anderen Tool und sogar lief es auf SQLCMD und konnte das gleiche Verhalten sehen :

enter image description here

Abgesehen davon, dass der "Befehl (e) erfolgreich." Nachricht erscheint nicht (dies muss ausschließlich von SSMS sein)

Wie auch immer, ich kann nicht erklären, aber ich kann es erraten. Ich kann mir vorstellen, dass dies passiert, weil die delete-Anweisung etwas anderes (oder weniger) als Insert und Update tut. Der Kompilierungsprozess gliedert sich in vier Teile: Parsen, Normalisieren, Kompilieren und Optimieren. Ich nehme an, dass etwas in diesen Schritten durch die DELETE-Anweisung anders gemacht wird, deshalb erhalten wir ein anderes Ergebnis

+0

Vielen Dank für Ihr Interesse. Ich glaube nicht, dass wir die Antwort finden werden, wenn wir uns nicht den SQL-Server-Code ansehen ... – ogun

+0

Ja, ich denke, das kommt nicht in Frage :) Ich frage mich, ob jemand das als "Bug" einreichen könnte? oder zumindest als irgendwo für eine Erklärung – Diego