2017-01-25 3 views
0

Ich möchte überprüfen, ob die SQL-Skripte, die ich geschrieben habe, auf SQL Server unabhängig von der SQL Server-Version (oder ab einer bestimmten SQL Server-Version) erfolgreich ausgeführt werden.Wie kann man wissen, in welcher Version SQL Server eine bestimmte Funktion unterstützt?

Zum Beispiel: Wie kann ich überprüfen, ob die folgende SQL-Anweisung in alten SQL Server-Versionen funktioniert?

UPDATE TABLE_A 
SET TABLE_A.COL_1= TABLE_B.COL_1 
FROM TABLE_A AS TABLE_A 
LEFT JOIN 
TABLE_B AS TABLE_B 
ON (TABLE_A.COL_ID=TABLE_B.COL_ID); 
+0

Diese Abfrage wird mit jeder Version oder Edition funktionieren, also keine Sorge. –

+0

@ M.Ali Ich denke, OP bedeutete dies nur als Beispiel und könnte komplexere Abfragen überprüfen. –

+0

@M.Ali Danke! Kann ich fragen, ob das auch für folgendes gilt? INSERT INTO TABLE_A (COLA_ID, COLA_1, COLA_2) \t SELECT COLB_ID, COLB_1, COLB_2 VON TABLE_B; –

Antwort

1

Durch Ändern der Kompatibilitätsebene können Sie eine ältere/andere Version von SQL Server "simulieren". So können Sie den Kompatibilitätsgrad vor dem Ausführen der Abfrage ändern, um festzustellen, ob eine bestimmte Abfrage mit einer bestimmten Version von SQL Server ordnungsgemäß ausgeführt wird. Hier

ist die Syntax:

ALTER DATABASE [YourDBname] SET COMPATIBILITY_LEVEL = x 

wobei x die Kompatibilitätsgrad:

  • 140: SQL Server vNext
  • 130: SQL Server 2016
  • 120: SQL-Datenbank
  • 120: SQL Server 2014
  • 110: S QL Server 2012
  • 105: SQL Server 2008 R2
  • 100: SQL Server 2008
  • 90: SQL Server 2005
  • 80: SQL Server 2000

MSDN für mehr Details

Zum Beispiel wurde die string_split()-Funktion in SQL Server 2016 (Kompatibilitätsstufe 130) eingeführt. Daher wird eine Abfrage ausgeführt, die string_split() mit einem Kompatibilitätsgrad enthält unter 130 würde zu einem Fehler:

ALTER DATABASE [YourDBname] SET COMPATIBILITY_LEVEL = 130 
go 
select value from string_split('1_2_3_4','_') 

ALTER DATABASE [YourDBname] SET COMPATIBILITY_LEVEL = 120 
go 
select value from string_split('1_2_3_4','_') 

Die erste Abfrage korrekt ausgeführt wird, während der zweite den folgenden Fehler geben:

Msg 208, Level 16, State 1, Line 9 Invalid object name 'string_split'.


Edit: Wie wies darauf hin, von Damien_The_Unbeliever in Kommentaren gibt es einige Einschränkungen mit diesen Ansatz. Jede Version von SQL Server kann nur eine begrenzte Anzahl von Kompatibilitätsgradwerten unterstützen.

Laut hier MSDN werden unterstützt Kompatibilitätsgrad Werte für jede Version (weitere Informationen here):

+--------------------+--------------------------------------+ 
|  Product  | Supported Compatibility Level Values | 
+--------------------+--------------------------------------+ 
| SQL Server vNext | 140, 130, 120, 110, 100    | 
| SQL Server 2016 | 130, 120, 110, 100     | 
| SQL Database  | 130, 120, 110, 100     | 
| SQL Server 2014 | 120, 110, 100      | 
| SQL Server 2012 | 110, 100, 90       | 
| SQL Server 2008 R2 | 100, 90, 80       | 
| SQL Server 2008 | 100, 90, 80       | 
| SQL Server 2005 | 90, 80        | 
| SQL Server 2000 | 80         | 
+--------------------+--------------------------------------+ 

Gemäß dieser Tabelle mit den neuesten Versionen von SQL Server (2016, 2014) können Sie gehen zurück bis SQL Server 2008, aber Sie können nicht zurück zu SQL Server 2005 oder 2000 gehen

+1

Möglicherweise benötigen Sie eine Reihe von Servern, wenn Sie alle Kompatibilitätsstufen testen möchten, da z. Ein 2014 (120) -Server kann nur die Kompatibilität zurück zu 2008 (100) herstellen. Ich denke, die allgemeine Richtlinie besagt, dass jede Version zwei Hauptversionen kompatibel machen kann. –

+0

@Damien_The_Unbeliever Ja, Sie haben Recht: wahrscheinlich ist es nicht möglich, alle SQL Server-Versionen mit dieser Technologie zu testen. Anscheinend mit meiner SQL Server 2016-Instanz bin ich in der Lage, zu Kompatibilitätsgrad 100 (SQL Server 2008) zurückzugehen, aber nicht weiter. – Andrea

+0

@Andrea Danke! das war so vorteilhaft. –

Verwandte Themen