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).

Transact-SQL-Syntaxkonventionen

Gilt für: SQL Server (SQL Server 2008 bis zur aktuellen Version), Azure SQL-Datenbank.

Syntax

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

Argumente

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

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

  Wert	Beschreibung	Gilt für
  80	SQL Server 2000	SQL Server 2008 bis SQL Server 2008 R2
  90	SQL Server 2005	SQL Server 2008 bis SQL Server 2012
  100	SQL Server 2008 und SQL Server 2008 R2	SQL Server 2008 bis SQL Server 2014
  110	SQL Server 2012	SQL Server 2012 bis SQL Server 2014
  120	SQL Server 2014	SQL Server 2014 bis SQL Server 2014

Hinweise

Bei allen Installationen von SQL Server 2014 ist der Standardkompatibilitätsgrad 120.In SQL Server 2014 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 2014-Version auf SQL Server aktualisiert wird, behält die Datenbank den vorhandenen Kompatibilitätsgrad, wenn dieser mindestens 100 ist.Wenn eine Datenbank mit dem Kompatibilitätsgrad 90 aktualisiert wird, wird der Kompatibilitätsgrad der Datenbank auf 100 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 auf vorhandene SQL Server 2014-Anwendungen auswirken, sollten Sie die Anwendung konvertieren, damit sie ordnungsgemäß funktioniert.Verwenden Sie dann die ALTER DATABASE-Anweisung, um den Kompatibilitätsgrad in 120 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 niedrigeren Kompatibilitätsgraden und Kompatibilitätsgrad 120

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

Kompatibilitätsgradeinstellung 110 oder niedriger	Kompatibilitätsgradeinstellung 120
Der ältere Abfrageoptimierer wird verwendet.	Die Komponente zum Erstellen und Optimieren von Abfrageplänen wurde in SQL Server 2014 deutlich verbessert.Diese neue Funktion des Abfrageoptimierers ist nur bei Verwendung des Datenbank-Kompatibilitätsgrads 120 verfügbar.Damit diese Verbesserungen optimal genutzt werden können, sollten neue Datenbankanwendungen mit dem Datenbank-Kompatibilitätsgrad 120 entwickelt werden.Von früheren SQL Server-Versionen migrierte Anwendungen sollten sorgfältig daraufhin überprüft werden, ob die bisherige gute Leistung aufrechterhalten bzw. verbessert wird.Wird die Leistung beeinträchtigt, können Sie den Kompatibilitätsgrad der Datenbank auf 110 oder einen niedrigeren Wert festlegen, um die ältere Methodologie des Abfrageoptimierers zu nutzen. Der Datenbank-Kompatibilitätsgrad 120 verwendet eine neue Kardinalitätsschätzung, die für moderne Data Warehousing- und OLTP-Arbeitsauslastungen optimiert ist.Bevor Sie den Datenbank-Kompatibilitätsgrad aufgrund von Leistungsproblemen auf 110 festlegen, sollten Sie die Empfehlungen im Abschnitt "Abfragepläne" des Themas SQL Server 2014Neuigkeiten (Datenbankmodul) lesen.
Bei Kompatibilitätsgraden unter 120 wird die Spracheinstellung beim Konvertieren eines date-Werts in einen Zeichenfolgenwert ignoriert.Beachten Sie, dass dieses Verhalten nur für den date-Typ spezifisch ist.Die folgende Abfrage ignoriert beispielsweise die SET LANGUAGE-Anweisung, es sei denn, es ist ein Kompatibilitätsgrad unter 120 festgelegt. SET DATEFORMAT dmy; DECLARE @t2 date = '12/5/2011' ; SET LANGUAGE dutch; SELECT CONVERT(varchar(11), @t2, 106); -- Results when the compatibility level is less than 120. 12 May 2011 -- Results when the compatibility level is set to 120). 12 mei 2011	Die Spracheinstellung wird nicht ignoriert, wenn ein date-Wert in eine Zeichenfolge konvertiert wird.
Rekursive Verweise auf der rechten Seite einer EXCEPT-Klausel erzeugen eine Endlosschleife.In folgendem Beispiel wird dieses Verhalten veranschaulicht. WITH cte AS (SELECT * FROM (VALUES (1),(2),(3)) v (a)), r AS (SELECT a FROM Table1 UNION ALL (SELECT a FROM Table1 EXCEPT SELECT a FROM r) ) SELECT a FROM r;	Rekursive Verweise in einer EXCEPT-Klausel generieren gemäß dem ANSI SQL-Standard einen Fehler.
Der rekursive CTE lässt doppelte Spaltennamen zu.	Der rekursive CTE lässt keine doppelten Spaltennamen zu.
Deaktivierte Trigger werden aktiviert, wenn die Trigger geändert werden.	Das Ändern eines Triggers ändert nicht den Status (deaktiviert oder aktiviert) des Triggers.
Die OUTPUT INTO-Tabellenklausel ignoriert die Einstellung IDENTITY_INSERT SETTING = OFF. Explizite Werte können eingefügt werden.	Sie können keine expliziten Werte für eine Identitätsspalte in einer Tabelle einfügen, wenn IDENTITY_INSERT auf OFF festgelegt ist.
Wenn die Datenbankkapselung auf PARTIAL festgelegt ist, kann die Überprüfung des $actions-Felds in der OUTPUT-Klausel einer MERGE-Anweisung einen Sortierungsfehler zurückgeben.	Die von der $actions-Klausel einer MERGE-Anweisung zurückgegebene Sortierung der Werte entspricht der Datenbanksortierung anstelle der Serversortierung. Es wird kein Sortierungskonfliktfehler zurückgegeben.
Durch eine SELECT INTO-Anweisung wird immer ein Singlethread-Einfügevorgang erstellt.	Durch eine SELECT INTO-Anweisung kann ein paralleler Einfügevorgang erstellt werden.Beim Einfügen großer Zeilenanzahlen kann die Leistung durch den parallelen Vorgang verbessert werden.

Unterschiede zwischen niedrigeren Kompatibilitätsgraden und Kompatibilitätsgraden 110 und 120

In diesem Abschnitt werden neue mit Kompatibilitätsgrad 110 eingeführte Verhaltensweisen beschrieben.Dieser Abschnitt bezieht sich auch auf Kompatibilitätsgrad 120.

Kompatibilitätsgradeinstellung 100 oder niedriger	Kompatibilitätsgradeinstellung 110 oder höher
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: H oder W in Großbuchstaben werden beim Trennen von zwei Konsonanten ignoriert, die die gleiche Zahl im SOUNDEX-Code aufweisen. 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: Wenn H oder W in Großbuchstaben zwei Konsonanten trennt, die die gleiche Zahl im SOUNDEX-Code aufweisen, wird der rechts stehende Konsonant ignoriert. 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).

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.	Niedrig
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.	Niedrig
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.	Niedrig
Die Verwendung des <dml_table_source>-Arguments der INSERT-Anweisung löst einen Syntaxfehler aus.	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.	Niedrig
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.	Niedrig
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.	Niedrig
CUBE und ROLLUP werden nicht als reservierte Schlüsselwörter erzwungen.	CUBE und ROLLUP sind reservierte Schlüsselwörter innerhalb der GROUP BY-Klausel.	Niedrig
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.	Niedrig
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(.) != "xsi-Namespace-URI einfügen" 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.	Niedrig
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"	Niedrig
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.	Niedrig
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.	Niedrig
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.	Niedrig
Die Aktualisierung von Spalten mithilfe einer zweiseitigen Zuweisung, wie z.&#160;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.&#160;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.	Niedrig
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;	Niedrig
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.&#160;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.	Niedrig
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".	Niedrig
Für systeminterne datetime-Funktionen, wie z.&#160;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.&#160;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

Reservierte Schlüsselwörter

Die Kompatibilitätseinstellung bestimmt außerdem die für das 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
120	Keine
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, 110 und 120 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

ALTER DATABASE (Transact-SQL)
Reservierte Schlüsselwörter (Transact-SQL)
CREATE DATABASE (SQL Server Transact-SQL)
DATABASEPROPERTYEX (Transact-SQL)
sys.databases (Transact-SQL)
sys.database_files (Transact-SQL)