Wann sollte ich Semikolons in SQL Server verwenden?

Beim Überprüfen von Code im Web und von SQL Server Management Studio generierten Skripten habe ich festgestellt, dass einige Anweisungen mit einem Semikolon beendet werden.

Wann sollte ich es verwenden?

Aus einem SQLServerCentral.Com- Artikel von Ken Powers:

Das Semikolon

Das Semikolon ist ein Anweisungsabschluss. Es ist Teil des ANSI SQL-92-Standards, wurde jedoch nie in Transact-SQL verwendet. In der Tat war es möglich, T-SQL jahrelang zu codieren, ohne jemals auf ein Semikolon zu stoßen.

Verwendung

Es gibt zwei Situationen, in denen Sie das Semikolon verwenden müssen. In der ersten Situation verwenden Sie einen Common Table Expression (CTE), und der CTE ist nicht die erste Anweisung im Stapel. In der zweiten Anweisung geben Sie eine Service Broker-Anweisung aus, und die Service Broker-Anweisung ist nicht die erste Anweisung im Stapel.

Standardmäßig werden SQL-Anweisungen mit Semikolons abgeschlossen. Sie verwenden ein Semikolon, um Anweisungen zu beenden, es sei denn, Sie haben (selten) einen neuen Anweisungsabschluss festgelegt.

Wenn Sie nur eine Anweisung senden, können Sie technisch auf den Anweisungsabschluss verzichten. Wenn Sie in einem Skript mehr als eine Anweisung senden, benötigen Sie diese.

Fügen Sie in der Praxis immer den Terminator ein, auch wenn Sie nur eine Anweisung an die Datenbank senden.

Bearbeiten: Als Antwort auf die Aussage, dass Anweisungsabschlusszeichen von [bestimmten RDBMS] nicht benötigt werden, obwohl dies wahr sein kann, werden sie vom ANSI SQL Standard benötigt. Wenn wir bei der gesamten Programmierung einen Standard ohne Funktionsverlust einhalten können, sollten wir dies tun, da dann weder unser Code noch unsere Gewohnheiten an einen proprietären Anbieter gebunden sind.

Bei einigen C-Compilern ist es möglich, dass die Hauptrückgabe ungültig ist, obwohl der Standard erfordert, dass main int zurückgibt. Dies macht unseren Code und uns selbst jedoch weniger portabel.

Die größte Schwierigkeit beim effektiven Programmieren besteht nicht darin, neue Dinge zu lernen, sondern schlechte Gewohnheiten zu verlernen. In dem Maße, in dem wir vermeiden können, schlechte Gewohnheiten zu erlangen, ist dies ein Gewinn für uns, für unseren Code und für jeden, der unseren Code liest oder verwendet.

In SQL2008 BOL heißt es, dass in den nächsten Versionen Semikolons erforderlich sein werden. Verwenden Sie es daher immer.

Referenz:

• Transact-SQL-Syntaxkonventionen (Transact-SQL)
• Veraltete Funktionen des Datenbankmoduls in SQL Server 2008 R2 (Abschnitt "In einer zukünftigen Version von SQL Server nicht unterstützte Funktionen", Abschnitt "Transact-SQL")

Sie müssen es verwenden.

Die Verwendung eines Semikolons zum Beenden von Anweisungen ist Standard und in mehreren anderen Datenbankplattformen erforderlich. SQL Server benötigt das Semikolon nur in bestimmten Fällen. In Fällen, in denen kein Semikolon erforderlich ist, verursacht die Verwendung eines Semikolons keine Probleme. Ich empfehle Ihnen dringend, alle Anweisungen mit einem Semikolon zu beenden. Dies verbessert nicht nur die Lesbarkeit Ihres Codes, sondern kann Ihnen in einigen Fällen auch Kummer ersparen. (Wenn ein Semikolon erforderlich ist und nicht angegeben wird, ist die Fehlermeldung, die SQL Server erzeugt, nicht immer sehr deutlich.)

Und das Wichtigste:

In der SQL Server-Dokumentation wird angegeben, dass das Nichtbeenden von T-SQL-Anweisungen mit einem Semikolon eine veraltete Funktion ist. Dies bedeutet, dass das langfristige Ziel darin besteht, die Verwendung des Semikolons in einer zukünftigen Version des Produkts zu erzwingen. Dies ist ein weiterer Grund, sich daran zu gewöhnen, alle Ihre Aussagen zu beenden, auch wenn dies derzeit nicht erforderlich ist.

Quelle: Microsoft SQL Server 2012 T-SQL-Grundlagen von Itzik Ben-Gan.

Ein Beispiel dafür, warum Sie immer verwenden müssen, ;sind die folgenden zwei Abfragen (aus diesem Beitrag kopiert ):

BEGIN TRY
    BEGIN TRAN
    SELECT 1/0 AS CauseAnException
    COMMIT
END TRY
BEGIN CATCH
    SELECT ERROR_MESSAGE()
    THROW
END CATCH

BEGIN TRY
    BEGIN TRAN
    SELECT 1/0 AS CauseAnException;
    COMMIT
END TRY
BEGIN CATCH
    SELECT ERROR_MESSAGE();
    THROW
END CATCH

Wenn ich dies richtig lese, müssen Semikolons zum Beenden von TSQL-Anweisungen verwendet werden. http://msdn.microsoft.com/en-us/library/ms143729%28v=sql.120%29.aspx

BEARBEITEN: Ich habe ein Plug-In für SSMS 2008R2 gefunden, das Ihr Skript formatiert und die Semikolons hinzufügt. Ich denke, es ist noch in der Beta ...

http://www.tsqltidy.com/tsqltidySSMSAddin.aspx

EDIT: Ich habe ein noch besseres kostenloses Tool / Plugin namens ApexSQL gefunden ... http://www.apexsql.com/

Persönliche Meinung: Verwenden Sie sie nur dort, wo sie benötigt werden. (Die erforderliche Liste finden Sie in der obigen Antwort von TheTXI.)

Da der Compiler sie nicht benötigen, Sie können sie überall setzen, aber warum? Der Compiler teilt Ihnen nicht mit, wo Sie einen vergessen haben, sodass Sie am Ende eine inkonsistente Verwendung haben.

[Diese Meinung gilt speziell für SQL Server. Andere Datenbanken stellen möglicherweise strengere Anforderungen. Wenn Sie SQL für die Ausführung auf mehreren Datenbanken schreiben, können Ihre Anforderungen variieren.]

tpdi sagte oben: "Wenn Sie in einem Skript mehr als eine Anweisung senden, benötigen Sie diese." Das stimmt eigentlich nicht. Du brauchst sie nicht.

PRINT 'Semicolons are optional'
PRINT 'Semicolons are optional'
PRINT 'Semicolons are optional';
PRINT 'Semicolons are optional';

Ausgabe:

Semicolons are optional
Semicolons are optional
Semicolons are optional
Semicolons are optional

Ich muss noch viel über T-SQL lernen, aber als ich Code für eine Transaktion ausarbeitete (und Code anhand von Beispielen aus Stackoverflow und anderen Sites basierte), fand ich einen Fall, in dem ein Semikolon erforderlich zu sein scheint und wenn es fehlt, Die Anweisung scheint überhaupt nicht ausgeführt zu werden und es wird kein Fehler ausgegeben. Dies scheint in keiner der obigen Antworten behandelt zu werden. (Dies war mit MS SQL Server 2012.)

Nachdem die Transaktion so funktioniert hatte, wie ich es wollte, habe ich beschlossen, sie mit einem Try-Catch zu versehen, damit sie bei Fehlern zurückgesetzt wird. Erst danach wurde die Transaktion nicht festgeschrieben (SSMS bestätigt dies, wenn versucht wird, das Fenster mit einer netten Nachricht zu schließen, die Sie darauf hinweist, dass eine nicht festgeschriebene Transaktion vorliegt.

Also das

COMMIT TRANSACTION 

außerhalb eines BEGIN TRY / END TRY-Blocks funktionierte das Festschreiben der Transaktion einwandfrei, aber innerhalb des Blocks musste es sein

COMMIT TRANSACTION;

Beachten Sie, dass kein Fehler oder keine Warnung bereitgestellt wird und kein Hinweis darauf vorliegt, dass die Transaktion bis zum Versuch, die Registerkarte "Abfrage" zu schließen, immer noch nicht festgeschrieben ist.

Glücklicherweise verursacht dies ein so großes Problem, dass sofort klar ist, dass es ein Problem gibt. Da leider kein Fehler (Syntax oder anderweitig) gemeldet wird, war das Problem nicht sofort ersichtlich.

Im Gegensatz dazu scheint ROLLBACK TRANSACTION im BEGIN CATCH-Block mit oder ohne Semikolon gleich gut zu funktionieren.

Es mag eine Logik dafür geben, aber es fühlt sich willkürlich und Alice im Wunderland an.

Es scheint , dass Semikolons sollte nicht in Verbindung mit Cursor - Operationen verwendet werden: OPEN, FETCH, CLOSEund DEALLOCATE. Ich habe nur ein paar Stunden damit verschwendet. Ich habe mir die BOL genau angesehen und festgestellt, dass [;] in der Syntax für diese Cursoranweisungen nicht angezeigt wird !!

So hatte ich:

OPEN mycursor;

und das gab mir Fehler 16916.

Aber:

OPEN mycursor

hat funktioniert.

Gemäß Transact-SQL-Syntaxkonventionen (Transact-SQL) (MSDN)

Transact-SQL-Anweisungsabschluss. Obwohl das Semikolon für die meisten Anweisungen in dieser Version von SQL Server nicht erforderlich ist, wird es in einer zukünftigen Version benötigt.

(siehe auch den Kommentar von @gerryLowry)

Wenn Sie eine DISABLE- oder ENABLE TRIGGER-Anweisung in einem Stapel verwenden, der andere Anweisungen enthält, muss die Anweisung unmittelbar davor mit einem Semikolon enden. Andernfalls wird ein Syntaxfehler angezeigt. Ich habe mir mit diesem die Haare ausgerissen ... Und danach bin ich über dieses MS Connect-Objekt über dasselbe gestolpert. Es ist geschlossen, da es nicht repariert werden kann.

siehe hier

Hinweis: Dies beantwortet die Frage wie geschrieben, aber nicht das angegebene Problem. Fügen Sie es hier hinzu, da die Leute danach suchen werden

Semikolon wird zuvor auch WITHin rekursiven CTE-Anweisungen verwendet:

;WITH Numbers AS
(
    SELECT n = 1
    UNION ALL
    SELECT n + 1
    FROM Numbers
    WHERE n+1 <= 10
)
SELECT n
FROM Numbers

Diese Abfrage generiert einen CTE namens Numbers, der aus Ganzzahlen besteht [1..10]. Dazu erstellen Sie eine Tabelle mit nur dem Wert 1 und wiederholen diese, bis Sie 10 erreichen.

Wenn Sie zufällige Command Timeout- Fehler in SQLServer erhalten möchten, lassen Sie das Semikolon am Ende Ihrer CommandText-Zeichenfolgen weg.

Ich weiß nicht, ob dies irgendwo dokumentiert ist oder ob es sich um einen Fehler handelt, aber es passiert und ich habe dies aus bitterer Erfahrung gelernt.

Ich habe überprüfbare und reproduzierbare Beispiele mit SQLServer 2008.

aka -> Fügen Sie in der Praxis immer den Terminator ein, auch wenn Sie nur eine Anweisung an die Datenbank senden.

Semikolons funktionieren nicht immer in zusammengesetzten SELECT-Anweisungen.

Vergleichen Sie diese beiden unterschiedlichen Versionen einer trivialen zusammengesetzten SELECT-Anweisung.

Der Code

DECLARE @Test varchar(35); 
SELECT @Test=
    (SELECT 
        (SELECT 
            (SELECT 'Semicolons do not always work fine.';););); 
SELECT @Test Test;

kehrt zurück

Msg 102, Level 15, State 1, Line 5
Incorrect syntax near ';'.

Allerdings der Code

DECLARE @Test varchar(35)
SELECT @Test=
    (SELECT 
        (SELECT 
            (SELECT 'Semicolons do not always work fine.'))) 
SELECT @Test Test

kehrt zurück

Test
-----------------------------------
Semicolons do not always work fine.

(1 row(s) affected)