ALTER DATABASE-Kompatibilitätsgrad (Transact-SQL)

Legt für bestimmte Verhalten der Datenbank fest, dass sie mit der angegebenen Version von SQL Server kompatibel sein müssen. Weitere ALTER DATABASE-Optionen finden Sie unter ALTER DATABASE (Transact-SQL).

Themenlink (Symbol) Transact-SQL-Syntaxkonventionen

Syntax

ALTER DATABASE database_name 
SET COMPATIBILITY_LEVEL = { 90 | 100 | 110 }

Argumente

  • database_name
    Der Name der Datenbank, die geändert werden soll.

  • COMPATIBILITY_LEVEL { 90 | 100 | 110 }
    Die SQL Server-Version, mit der die Datenbank kompatibel sein soll. Folgende Werte sind zulässig:

    90 = SQL Server 2005

    100 = SQL Server 2008 und SQL Server 2008 R2

    110 = SQL Server 2012

Hinweise

Bei allen Installationen von SQL Server 2012 ist der Standardkompatibilitätsgrad 110. In SQL Server 2012 erstellte Datenbanken sind auf diesen Grad festgelegt, sofern der Kompatibilitätsgrad der model-Datenbank nicht niedriger ist. Wenn eine Datenbank von einer früheren SQL Server-Version auf SQL Server 2012 aktualisiert wird, behält die Datenbank den vorhandenen Kompatibilitätsgrad, wenn dieser mindestens 90 ist. Wird eine Datenbank mit einem Kompatibilitätsgrad unter 90 aktualisiert, dann wird der Kompatibilitätsgrad der Datenbank auf 90 festgelegt. Dies gilt sowohl für die System- als auch für die Benutzerdatenbanken. Verwenden Sie die ALTER DATABASE-Anweisung, um den Kompatibilitätsgrad der Datenbank zu ändern. Zum Anzeigen des aktuellen Kompatibilitätsgrads der Datenbank fragen Sie die compatibility_level-Spalte in der sys.databases-Katalogsicht ab.

Verwenden des Kompatibilitätsgrads für die Abwärtskompatibilität

Der Kompatibilitätsgrad wirkt sich nicht auf den gesamten Server, sondern nur auf das Verhalten der angegebenen Datenbank aus. Der Kompatibilitätsgrad bietet nur partielle Abwärtskompatibilität mit früheren Versionen von SQL Server. Verwenden Sie den Kompatibilitätsgrad als vorläufige Migrationshilfe, um versionsbedingte Unterschiede in den Verhaltensweisen zu umgehen, die über die jeweilige Einstellung für den Kompatibilitätsgrad gesteuert werden. Wenn sich Verhaltensunterschiede in SQL Server 2012 auf vorhandene SQL Server-Anwendungen auswirken, sollten Sie die Anwendung konvertieren, damit sie ordnungsgemäß funktioniert. Verwenden Sie dann die ALTER DATABASE-Anweisung, um den Kompatibilitätsgrad in 100 zu ändern. Die neue Kompatibilitätseinstellung für eine Datenbank tritt in Kraft, wenn die Datenbank das nächste Mal zur aktuellen Datenbank wird (als Standarddatenbank bei der Anmeldung oder durch Angabe in einer USE-Anweisung).

Bewährte Methoden

Das Ändern des Kompatibilitätsgrades, während Benutzer mit der Datenbank verbunden sind, kann zu fehlerhaften Resultsets für aktive Abfragen führen. Wird der Kompatibilitätsgrad z. B. während der Kompilierung eines Abfrageplans geändert, basiert der kompilierte Plan möglicherweise sowohl auf dem alten als auch auf dem neuen Kompatibilitätsgrad, was zu einem fehlerhaften Plan und möglicherweise ungenauen Ergebnissen führt. Das Problem kann noch verstärkt werden, wenn der Plan im Plancache gespeichert und für nachfolgende Abfragen erneut verwendet wird. Zur Vermeidung ungenauer Ergebnisse wird zum Ändern des Kompatibilitätsgrades einer Datenbank das folgende Verfahren empfohlen:

  1. Versetzen Sie die Datenbank mithilfe von ALTER DATABASE SET SINGLE_USER in den Einzelbenutzermodus.

  2. Ändern Sie den Kompatibilitätsgrad der Datenbank.

  3. Versetzen Sie die Datenbank mithilfe von ALTER DATABASE SET MULTI_USER in den Mehrbenutzermodus.

  4. Weitere Informationen zum Festlegen des Zugriffs auf eine Datenbank finden Sie unter ALTER DATABASE (Transact-SQL).

Kompatibilitätsgrade und gespeicherte Prozeduren

Wenn eine gespeicherte Prozedur ausgeführt wird, verwendet sie den aktuellen Kompatibilitätsgrad der Datenbank, in der sie definiert ist. Wenn die Kompatibilitätseinstellung einer Datenbank geändert wird, werden alle zugehörigen gespeicherten Prozeduren automatisch entsprechend neu kompiliert.

Unterschiede zwischen Kompatibilitätsgrad 90 und Kompatibilitätsgrad 100

In diesem Abschnitt werden neue mit Kompatibilitätsgrad 100 eingeführte Verhaltensweisen beschrieben.

Kompatibilitätsgradeinstellung 90

Kompatibilitätsgradeinstellung 100

Mögliche Auswirkung

Die Einstellung QUOTED_IDENTIFER ist für Tabellenwertfunktionen mit mehreren Anweisungen immer auf ON festgelegt, wenn diese erstellt werden, unabhängig von der Einstellung auf Sitzungsebene.

Die QUOTED IDENTIFIER-Sitzungseinstellung wird berücksichtigt, wenn Tabellenwertfunktionen mit mehreren Anweisungen erstellt werden.

Mittel

Wenn Sie eine Partitionsfunktion erstellen oder ändern, werden die Literale datetime und smalldatetime in der Funktion ausgewertet, wobei angenommen wird, dass US_English die Sitzungssprache darstellt.

Die aktuelle Spracheinstellung wird verwendet, um die Literale datetime und smalldatetime in der Partitionsfunktion auszuwerten.

Mittel

Die FOR BROWSE-Klausel ist in INSERT- und SELECT INTO-Anweisungen zulässig (und wird ignoriert).

Die FOR BROWSE-Klausel ist in INSERT- und SELECT INTO-Anweisungen nicht zulässig.

Mittel

Volltextprädikate sind in der OUTPUT-Klausel zulässig.

Volltextprädikate sind in der OUTPUT-Klausel nicht zulässig.

Gering

CREATE FULLTEXT STOPLIST, ALTER FULLTEXT STOPLIST und DROP FULLTEXT STOPLIST werden nicht unterstützt. Die Systemstoppliste wird automatisch neuen Volltextindizes zugeordnet.

CREATE FULLTEXT STOPLIST, ALTER FULLTEXT STOPLIST und DROP FULLTEXT STOPLIST werden unterstützt.

Gering

MERGE wird nicht als reserviertes Schlüsselwort erzwungen.

MERGE ist ein vollständig reserviertes Schlüsselwort. Die MERGE-Anweisung wird bei den Kompatibilitätsgraden 100 und 90 unterstützt.

Gering

Die Verwendung des <dml_table_source->-Arguments der INSERT-Anweisung verursacht einen Syntaxfehler.

Sie können die Ergebnisse einer OUTPUT-Klausel in einer geschachtelten INSERT-, UPDATE-, DELETE- oder MERGE-Anweisung aufzeichnen und diese Ergebnisse in eine Zieltabelle oder -sicht einfügen. Dies erfolgt über das <dml_table_source>-Argument der INSERT-Anweisung.

Gering

DBCC CHECKDB oder CHECKTABLE führt sowohl physische als auch logische Konsistenzprüfungen für eine einzelne Tabelle oder indizierte Sicht und alle zugehörigen, nicht gruppierten Indizes und XML-Indizes aus, sofern nicht NOINDEX angegeben wird. Räumliche Indizes werden nicht unterstützt.

DBCC CHECKDB oder CHECKTABLE führt sowohl physische als auch logische Konsistenzprüfungen für eine einzelne Tabelle und alle zugehörigen, nicht gruppierten Indizes aus, sofern nicht NOINDEX angegeben wird. Allerdings werden für XML-Indizes, räumliche Indizes und indizierte Sichten standardmäßig nur physische Konsistenzprüfungen ausgeführt.

Bei Angabe von WITH EXTENDED_LOGICAL_CHECKS werden logische Konsistenzprüfungen für indizierte Sichten, XML-Indizes und räumliche Indizes (sofern vorhanden) ausgeführt. Standardmäßig werden physische Konsistenzprüfungen vor den logischen Konsistenzprüfungen ausgeführt. Wenn NOINDEX ebenfalls angegeben wird, werden nur die logischen Prüfungen ausgeführt.

Gering

Wenn eine OUTPUT-Klausel mit einer DML-Anweisung (Data Manipulation Language, Datenbearbeitungssprache) verwendet wird und während der Ausführung der Anweisung ein Laufzeitfehler auftritt, wird die gesamte Transaktion beendet, und es wird ein Rollback für sie ausgeführt.

Wenn eine OUTPUT-Klausel mit einer DML-Anweisung (Data Manipulation Language, Datenbearbeitungssprache) verwendet wird und während der Ausführung der Anweisung ein Laufzeitfehler auftritt, hängt das Verhalten von der SET XACT_ABORT-Einstellung ab. Wenn SET XACT_ABORT auf OFF festgelegt ist, führt ein Anweisungsabbruchfehler, der von der DML-Anweisung bei Verwendung der OUTPUT-Klausel generiert wird, zum Abbruch der Anweisung. Die Ausführung des Batches wird jedoch fortgesetzt, und es wird kein Rollback für die Transaktion ausgeführt. Wenn SET XACT_ABORT auf ON festgelegt ist, bewirken alle Laufzeitfehler, die von der DML-Anweisung bei Verwendung der OUTPUT-Klausel generiert werden, dass der Batch abgebrochen und für die Transaktion ein Rollback ausgeführt wird.

Gering

CUBE und ROLLUP werden nicht als reservierte Schlüsselwörter erzwungen.

CUBE und ROLLUP sind reservierte Schlüsselwörter innerhalb der GROUP BY-Klausel.

Gering

Für Elemente des anyType-XML-Datentyps wird die strict-Überprüfung angewendet.

Für Elemente des anyType-Datentyps wird die lax-Überprüfung angewendet. Weitere Informationen finden Sie unter Platzhalterkomponenten und Inhaltsüberprüfung.

Gering

Die speziellen Attribute xsi:nil und xsi:type können durch DML-Anweisungen nicht abgefragt oder geändert werden.

Dies hat zur Folge, dass /e/@xsi:nil fehlschlägt, während /e/@* die Attribute xsi:nil und xsi:type ignoriert. /e gibt jedoch die Attribute xsi:nil und xsi:type aus Gründen der Konsistenz mit SELECT xmlCol zurück, sogar wenn xsi:nil = "false".

Die speziellen Attribute xsi:nil und xsi:type werden als reguläre Attribute gespeichert und können abgefragt und geändert werden.

Beispielsweise gibt die Ausführung der Abfrage SELECT x.query('a/b/@*') alle Attribute einschließlich xsi:nil und xsi:type zurück. Um diese Typen in der Abfrage auszuschließen, ersetzen Sie @* durch @*[namespace-uri(.) != "insert xsi namespace uri" und nicht durch (local-name(.) = "type" oder local-name(.) ="nil".

Niedrig

Eine benutzerdefinierte Funktion, die eine XML-Zeichenfolgenkonstante in einen SQL Server-datetime-Typ konvertiert, wird als deterministisch gekennzeichnet.

Eine benutzerdefinierte Funktion, die eine XML-Zeichenfolgenkonstante in einen SQL Server-datetime-Typ konvertiert, wird als nicht deterministisch gekennzeichnet.

Gering

Die XML-Datentypen "union" und "list" werden nicht vollständig unterstützt.

Die XML-Datentypen "union" und "list" werden vollständig unterstützt, einschließlich der folgenden Funktionalität:

  • "union" von "list"

  • "union" von "union"

  • Liste der atomaren Typen

  • "list" von "union"

Gering

Die für eine xQuery-Methode erforderlichen SET-Optionen werden nicht überprüft, wenn die Methode in einer Sicht oder Inline-Tabellenwertfunktion enthalten ist.

Die für eine xQuery-Methode erforderlichen SET-Optionen werden überprüft, wenn die Methode in einer Sicht oder Inline-Tabellenwertfunktion enthalten ist. Wenn die SET-Optionen der Methode nicht ordnungsgemäß festgelegt sind, wird ein Fehler ausgegeben.

Gering

XML-Attributwerte, die Zeilenendezeichen enthalten (Wagenrücklauf und Zeilenvorschub) werden nicht gemäß dem XML-Standard normalisiert. Somit werden anstelle eines einzelnen Zeilenvorschubzeichens beide Zeichen zurückgegeben.

XML-Attributwerte, die Zeilenendezeichen enthalten (Wagenrücklauf und Zeilenvorschub) werden gemäß dem XML-Standard normalisiert. Somit werden alle Zeilenumbrüche in extern analysierten Entitäten (einschließlich der Dokumententität) bei Eingabe normalisiert, indem sowohl die aus zwei Zeichen bestehende Folge #xD #xA als auch alle Vorkommnisse von #xD, die nicht von #xA gefolgt werden, in das einzelne Zeichen #xA übersetzt werden.

Anwendungen, die mithilfe von Attributen Zeichenfolgenwerte transportieren, die Zeilenendezeichen enthalten, erhalten diese Zeichen nicht wie gesendet zurück. Um die Normalisierung zu verhindern, müssen für die Codierung aller Zeilenendezeichen numerische XML-Zeichenentitäten verwendet werden.

Gering

Die Spalteneigenschaften ROWGUIDCOL und IDENTITY können als Einschränkung falsch benannt werden. Beispielsweise wird die Anweisung CREATE TABLE T (C1 int CONSTRAINT MyConstraint IDENTITY) ausgeführt, doch wird der Einschränkungsname nicht beibehalten und ist für den Benutzer nicht verfügbar.

Die Spalteneigenschaften ROWGUIDCOL und IDENTITY können nicht als Einschränkung benannt werden. Der Fehler 156 wird zurückgegeben.

Gering

Die Aktualisierung von Spalten mithilfe einer zweiseitigen Zuweisung, wie z. B. UPDATE T1 SET @v = column_name = <expression> kann zu unerwarteten Ergebnissen führen, weil während der Ausführung der Anweisung anstelle deren Anfangswert der aktuelle Wert der Variablen in anderen Klauseln verwendet werden kann, wie z. B. in der WHERE- und ON-Klausel. Dies kann dazu führen, dass sich die Bedeutungen der Prädikate für jede Zeile einzeln unvorhersehbar ändern.

Dieses Verhalten gilt nur, wenn der Kompatibilitätsgrad auf 90 festgelegt ist.

Die Aktualisierung von Spalten mithilfe einer zweiseitigen Zuweisung liefert die erwarteten Ergebnisse, weil während der Ausführung der Anweisung nur auf den Anweisungsanfangswert der Spalte zugegriffen wird.

Gering

Die Variablenzuweisung ist in einer Anweisung mit einem UNION-Operator auf der obersten Ebene zulässig, kann jedoch unerwartete Ergebnisse zurückgeben. Beispielsweise wird in den folgenden Anweisungen der lokalen Variable @v der Wert der Spalte BusinessEntityID aus der Vereinigung von zwei Tabellen zugewiesen. Wenn die SELECT-Anweisung mehr als einen Wert zurückgibt, wird der Variablen definitionsgemäß der zuletzt zurückgegebene Wert zugewiesen. In diesem Fall wird der Variablen der letzte Wert richtig zugewiesen, es wird jedoch auch das Resultset der SELECT UNION-Anweisung zurückgegeben.

ALTER DATABASE AdventureWorks2012
SET compatibility_level = 90;
GO
USE AdventureWorks2012;
GO
DECLARE @v int;
SELECT @v = BusinessEntityID FROM HumanResources.Employee
UNION ALL
SELECT @v = BusinessEntityID FROM HumanResources.EmployeeAddress;
SELECT @v;

Die Variablenzuweisung ist in einer Anweisung mit einem UNION-Operator auf der obersten Ebene nicht zulässig. Der Fehler 10734 wird zurückgegeben.

Um den Fehler zu beheben, müssen Sie die Abfrage umschreiben, wie im folgenden Beispiel gezeigt.

DECLARE @v int;
SELECT @v = BusinessEntityID FROM 
    (SELECT BusinessEntityID FROM HumanResources.Employee
     UNION ALL
     SELECT BusinessEntityID FROM HumanResources.EmployeeAddress) AS Test;
SELECT @v;

Gering

Die ODBC-Funktion {fn CONVERT ()} verwendet das Standarddatumsformat der Sprache. Bei einigen Sprachen lautet das Standardformat YDM. Dies kann zu Konvertierungsfehlern führen, wenn CONVERT() mit anderen Funktionen kombiniert wird, die ein YMD-Format erwarten, wie z. B. mit {fn CURDATE()}.

Die ODBC-Funktion {fn CONVERT()} verwendet für die Konvertierung in die ODBC-Datentypen SQL_TIMESTAMP, SQL_DATE, SQL_TIME, SQLDATE, SQL_TYPE_TIME und SQL_TYPE_TIMESTAMP das sprachenunabhängige YMD-Format Stil 121.

Gering

Die ODBC-Funktion {fn CURDATE()} gibt nur das Datum im Format "YYYY-MM-DD" zurück.

Die ODBC-Funktion {fn CURDATE()} gibt Datum und Uhrzeit zurück. Beispiel: "YYYY-MM-DD hh:mm:ss".

Gering

Für systeminterne datetime-Funktionen, wie z. B. DATEPART, ist es nicht erforderlich, dass Zeichenfolgeneingabewerte gültige datetime-Literale sind. Beispielsweise wird SELECT DATEPART (year, '2007/05-30') erfolgreich kompiliert.

Für systeminterne datetime-Funktionen, wie z. B. DATEPART, ist es erforderlich, dass Zeichenfolgeneingabewerte gültige datetime-Literale sind. Fehler 241 wird zurückgegeben, wenn ein ungültiges datetime-Literal verwendet wird.

Niedrig

Unterschiede zwischen niedrigeren Kompatibilitätsgraden und Kompatibilitätsgrad 110

In diesem Abschnitt werden neue mit Kompatibilitätsgrad 110 eingeführte Verhaltensweisen beschrieben.

Kompatibilitätsgradeinstellung 100 oder niedriger

Kompatibilitätsgradeinstellung 110

Common Language Runtime (CLR)-Datenbankobjekte werden mit Version 4 der CLR ausgeführt. Einige in Version 4 der CLR eingeführte Verhaltensänderungen werden jedoch vermieden. Weitere Informationen finden Sie unter Neuigkeiten bei der CLR-Integration.

CLR-Datenbankobjekte werden mit Version 4 der CLR ausgeführt.

Die XQuery-Funktionen string-length und substring betrachten jedes Ersatzzeichen als zwei Zeichen.

Die XQuery-Funktionen string-length und substring betrachten jedes Ersatzzeichen als ein Zeichen.

PIVOT ist in einer rekursiven allgemeinen Tabellenausdrucksabfrage (CTE) zulässig. Die Abfrage gibt jedoch falsche Ergebnisse zurück, wenn mehrere Zeilen pro Gruppierung vorhanden sind.

PIVOT ist in einer rekursiven allgemeinen Tabellenausdrucksabfrage (CTE) nicht zulässig. Es wird ein Fehler zurückgegeben.

Der RC4-Algorithmus wird nur aus Gründen der Abwärtskompatibilität unterstützt. Neues Material kann nur mit RC4 oder RC4_128 verschlüsselt werden, wenn die Datenbank den Kompatibilitätsgrad 90 oder 100 besitzt. (Nicht empfohlen.) In SQL Server 2012 kann mit RC4 oder RC4_128 verschlüsseltes Material in jedem Kompatibilitätsgrad entschlüsselt werden.

Neues Material kann nicht mit RC4 oder RC4_128 verschlüsselt werden. Verwenden Sie stattdessen einen neueren Algorithmus, z. B. einen der AES-Algorithmen. In SQL Server 2012 kann mit RC4 oder RC4_128 verschlüsseltes Material in jedem Kompatibilitätsgrad entschlüsselt werden.

Das Standardformat für CAST- und CONVERT-Vorgänge an den Datentypen time und datetime2 ist 121, es sei denn, einer der Typen wird in einem berechneten Spaltenausdruck verwendet. Für berechnete Spalten ist das Standardformat 0. Dieses Verhalten wirkt sich auf berechnete Spalten aus, wenn sie erstellt werden und in Abfragen mit automatischer Parametrisierung oder in Einschränkungsdefinitionen verwendet werden.

Im folgenden Beispiel wird der Unterschied zwischen den Formaten 0 und 121 verdeutlicht. Das oben beschriebene Verhalten wird nicht veranschaulicht. Weitere Informationen zu Datums- und Zeitformaten finden Sie unter CAST und CONVERT (Transact-SQL).

CREATE TABLE t1 (c1 time(7), c2 datetime2); 
INSERT t1 (c1,c2) VALUES (GETDATE(), GETDATE());
SELECT CONVERT(nvarchar(16),c1,0) AS TimeStyle0
       ,CONVERT(nvarchar(16),c1,121)AS TimeStyle121
       ,CONVERT(nvarchar(32),c2,0) AS Datetime2Style0
       ,CONVERT(nvarchar(32),c2,121)AS Datetime2Style121
FROM t1;
-- Returns values such as the following.
TimeStyle0       TimeStyle121     Datetime2Style0      Datetime2Style121
---------------- ---------------- -------------------- --------------------------
3:15PM           15:15:35.8100000 Jun  7 2011  3:15PM  2011-06-07 15:15:35.8130000

Unter dem Kompatibilitätsgrad 110 ist das Standardformat für CAST- und CONVERT-Vorgänge im Fall der Datentypen time und datetime2 immer 121. Basiert die Abfrage auf dem alten Verhalten, verwenden Sie einen Kompatibilitätsgrad unter 110, oder geben Sie in der betroffenen Abfrage explizit das Format 0 an.

Ein Update der Datenbank auf Kompatibilitätsgrad 110 ändert keine Benutzerdaten, die auf dem Datenträger gespeichert wurden. Sie müssen diese Daten entsprechend manuell korrigieren. Haben Sie beispielsweise SELECT INFO zum Erstellen einer Tabelle von einer Quelle verwendet, die einen Ausdruck für eine berechnete Spalte (oben beschrieben) beinhaltete, werden die Daten mit dem Format 0 anstelle der Definition der berechneten Spalte an sich gespeichert. Sie müssen diese Daten manuell aktualisieren, um sie an das Format 121 anzupassen.

Alle Spalten in Remotetabellen des Typs smalldatetime, auf die in einer partitionierten Sicht verwiesen wird, werden als datetime zugeordnet. Entsprechende Spalten in lokalen Tabellen (in derselben Ordnungsposition in der Auswahlliste) müssen den Typ datetime aufweisen.

Alle Spalten in Remotetabellen des Typs smalldatetime, auf die in einer partitionierten Sicht verwiesen wird, werden als smalldatetime zugeordnet. Entsprechende Spalten in lokalen Tabellen (in derselben Ordnungsposition in der Auswahlliste) müssen den Typ smalldatetime aufweisen.

Nach dem Upgrade auf 110 schlägt die verteilte partitionierte Sicht wegen des Datentypkonflikts fehl. Sie können dieses Problem beheben, indem Sie den Datentyp in der Remotetabelle in datetime ändern oder den Kompatibilitätsgrad der lokalen Datenbank auf höchstens 100 setzen.

SOUNDEX-Funktion implementiert die folgenden Regeln:

  1. H oder W in Großbuchstaben werden beim Trennen von zwei Konsonanten ignoriert, die die gleiche Zahl im SOUNDEX-Code aufweisen.

  2. Wenn die ersten beiden Zeichen von character_expression die gleiche Zahl im SOUNDEX-Code aufweisen, werden beide Zeichen eingeschlossen. Wenn ein Satz nebeneinander liegender Konsonanten die gleiche Zahl im SOUNDEX-Code aufweist, werden andernfalls alle Zeichen außer dem ersten Zeichen ausgeschlossen.

SOUNDEX-Funktion implementiert die folgenden Regeln:

  1. Wenn H oder W in Großbuchstaben zwei Konsonanten trennt, die die gleiche Zahl im SOUNDEX-Code aufweisen, wird der rechts stehende Konsonant ignoriert.

  2. Wenn ein Satz nebeneinander liegender Konsonanten die gleiche Zahl im SOUNDEX-Code aufweist, werden andernfalls alle Zeichen außer dem ersten Zeichen ausgeschlossen.

Die zusätzlichen Regeln führen möglicherweise dazu, dass die von der SOUNDEX-Funktion berechneten Werte sich von den unter früheren Kompatibilitätsgraden berechneten Werten unterscheiden. Möglicherweise sind die Indizes, Heaps oder CHECK-Einschränkungen, die die SOUNDEX-Funktion verwenden, nach dem Upgrade auf Kompatibilitätsgrad 110 erneut zu erstellen. Weitere Informationen finden Sie unter SOUNDEX (Transact-SQL).

Reservierte Schlüsselwörter

Die Kompatibilitätseinstellung bestimmt außerdem die für das Database Engine (Datenbankmodul) reservierten Schlüsselwörter. In der folgenden Tabelle sind die reservierten Schlüsselwörter aufgeführt, die mit den einzelnen Kompatibilitätsgraden eingeführt werden.

Einstellung für den Kompatibilitätsgrad

Reservierte Schlüsselwörter

110

WITHIN GROUP, TRY_CONVERT, SEMANTICKEYPHRASETABLE, SEMANTICSIMILARITYDETAILSTABLE, SEMANTICSIMILARITYTABLE

100

CUBE, MERGE, ROLLUP

90

EXTERNAL, PIVOT, UNPIVOT, REVERT, TABLESAMPLE

Bei einem bestimmten Kompatibilitätsgrad schließen die reservierten Schlüsselwörter alle Schlüsselwörter ein, die mit diesem oder einem niedrigeren Grad eingeführt wurden. So stellen z. B. bei Anwendungen mit dem Kompatibilitätsgrad 110 alle in der vorherigen Tabelle aufgeführten Schlüsselwörter reservierte Schlüsselwörter dar. Bei den niedrigeren Kompatibilitätsgraden stellen die Schlüsselwörter von Grad 100 weiterhin gültige Objektnamen dar; die Sprachfunktionen von Grad 110, die diesen Schlüsselwörtern entsprechen, sind jedoch nicht verfügbar.

Nach der Einführung bleibt ein Schlüsselwort reserviert. So stellt z. B. das reservierte Schlüsselwort PIVOT, das mit dem Kompatibilitätsgrad 90 eingeführt wurde, auch bei Grad 100 und 110 ein reserviertes Schlüsselwort dar.

Wenn eine Anwendung einen Bezeichner verwendet, der für den Kompatibilitätsgrad der Anwendung als Schlüsselwort reserviert ist, erzeugt die Anwendung einen Fehler. Sie können dies umgehen, indem Sie den Bezeichner in eckige Klammern ([ ]) oder Anführungszeichen (" ") einschließen. Wenn Sie z. B. eine Anwendung, die den Bezeichner EXTERNAL verwendet, auf den Kompatibilitätsgrad 90 aktualisieren möchten, können Sie den Bezeichner ändern, sodass er anschließend entweder [EXTERNAL] oder "EXTERNAL" lautet.

Weitere Informationen finden Sie unter Reservierte Schlüsselwörter (Transact-SQL).

Berechtigungen

Erfordert die ALTER-Berechtigung für die Datenbank.

Beispiele

A.Ändern des Kompatibilitätsgrads

Im folgenden Beispiel wird der Kompatibilitätsgrad der AdventureWorks2012 -Datenbank in 110, SQL Server 2012 geändert.

ALTER DATABASE AdventureWorks2012
SET COMPATIBILITY_LEVEL = 110;
GO

Siehe auch

Verweis

ALTER DATABASE (Transact-SQL)

Reservierte Schlüsselwörter (Transact-SQL)

CREATE DATABASE (Transact-SQL)

DATABASEPROPERTYEX (Transact-SQL)

sys.databases (Transact-SQL)

sys.database_files (Transact-SQL)