Artikel
09/24/2010

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. Die folgende in SQL Server 2008 neu eingeführte ALTER DATABASE-Syntax ersetzt die sp_dbcmptlevel-Prozedur zum Festlegen des Datenbank-Kompatibilitätsgrads. Weitere ALTER DATABASE-Optionen finden Sie unter ALTER DATABASE (Transact-SQL).

Themenlink (Symbol) Transact-SQL-Syntaxkonventionen

Syntax

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

Argumente

database_name
Der Name der Datenbank, die geändert werden soll.
COMPATIBILITY_LEVEL { 80 | 90 | 100 }
Die SQL Server-Version, mit der die Datenbank kompatibel sein soll. Folgende Werte sind zulässig:

80 = SQL Server 2000

90 = SQL Server 2005

100 = SQL Server 2008

Hinweise

Bei allen Installationen von SQL Server 2008 ist der Standardkompatibilitätsgrad 100. In SQL Server 2008 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 2008 aktualisiert wird, behält die Datenbank den vorhandenen Kompatibilitätsgrad, wenn dieser mindestens 80 ist. Wird eine Datenbank mit einem Kompatibilitätsgrad unter 80 aktualisiert, dann wird der Kompatibilitätsgrad der Datenbank auf 80 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 2008 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 Abfrageplanes 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:

Versetzen Sie die Datenbank mithilfe von ALTER DATABASE SET SINGLE_USER in den Einzelbenutzermodus.
Ändern Sie den Kompatibilitätsgrad der Datenbank.
Versetzen Sie die Datenbank mithilfe von ALTER DATABASE SET MULTI_USER in den Mehrbenutzermodus.
Weitere Informationen zum Festlegen des Zugriffs auf eine Datenbank finden Sie unter ALTER DATABASE (Transact-SQL).

SET-Optionen

Neue Funktionen sind möglicherweise mit älteren Kompatibilitätsgraden funktionsfähig, die SET-Optionen erfordern jedoch ggf. Anpassungen. Beispielsweise müssen die ANSI SET-Optionen entsprechend festgelegt werden, wenn der xml-Datentyp beim Kompatibilitätsgrad 80 verwendet werden soll. Zudem gilt, wenn der Kompatibilitätsgrad der Datenbank auf 90 oder höher festgelegt ist, wird durch Festlegen von ANSI_WARNINGS auf ON implizit auch ARITHABORT auf ON festgelegt. Wenn der Kompatibilitätsgrad der Datenbank auf 80 festgelegt wird, muss die Option ARITHABORT explizit auf ON festgelegt werden. Weitere Informationen finden Sie unter SET-Optionen mit Auswirkungen auf Ergebnisse.

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 80 und Kompatibilitätsgrad 100

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

Die Verwendung des Kompatibilitätsgrads 90 kann zu den im Folgenden beschriebenen Verhaltensänderungen führen.

Kompatibilitätsgradeinstellung 80	Kompatibilitätsgradeinstellung 90	Mögliche Auswirkung
Bei Sperrhinweisen in der FROM-Klausel ist das WITH-Schlüsselwort immer optional.	Bis auf einige Ausnahmen werden Tabellenhinweise nur dann in der FROM-Klausel unterstützt, wenn die Hinweise mit dem WITH-Schlüsselwort angegeben werden. Weitere Informationen finden Sie unter FROM (Transact-SQL).	Hoch
Die Operatoren = und = für äußere Verknüpfungen werden unterstützt, wobei jedoch eine Warnmeldung ausgegeben wird.	Diese Operatoren werden nicht unterstützt. Stattdessen sollte das OUTER JOIN-Schlüsselwort verwendet werden.	Hoch
Werden die Spaltenverweise in der ORDER BY-Liste an die durch die SELECT-Liste definierten Spalten gebunden, werden Spaltenmehrdeutigkeiten ignoriert. Spaltenpräfixe werden manchmal ignoriert. Möglicherweise wird dadurch das Resultset in einer unerwarteten Reihenfolge zurückgegeben. Beispielweise wird eine ORDER BY-Klausel mit einer einzelnen zweiteiligen Spalte (<table_alias>.<column>), die als Verweis auf eine Spalte in einer SELECT-Liste verwendet wird, akzeptiert, der Tabellenalias wird jedoch ignoriert. Betrachten Sie die folgende Abfrage. SELECT c1 = -c1 FROM t_table AS x ORDER BY x.c1 Bei der Ausführung wird das Spaltenpräfix in der ORDER BY-Klausel ignoriert. Der Sortiervorgang wird nicht wie erwartet für die angegebene Quellspalte (x.c1) ausgeführt, sondern für die abgeleitete c1-Spalte, die in der Abfrage definiert wird. Der Ausführungsplan für die Abfrage zeigt, dass zunächst die Werte für die abgeleitete Spalte berechnet werden und dann die berechneten Werte sortiert werden.	Eine Spaltenmehrdeutigkeit löst einen Fehler aus. Spaltenpräfixe, die ggf. in ORDER BY angegeben sind, werden nicht ignoriert, wenn eine Bindung an eine Spalte erfolgt, die in der SELECT-Liste definiert ist. Betrachten Sie die folgende Abfrage. SELECT c1 = -c1 FROM t_table AS x ORDER BY x.c1 Bei der Ausführung wird das Spaltenpräfix in der ORDER BY-Klausel nicht ignoriert. Der Sortiervorgang findet wie erwartet für die angegebene Quellspalte (x.c1) statt. Der Ausführungsplan für die Abfrage zeigt, dass die von t_table zurückgegebenen Zeilen vom Sortieroperator geordnet werden und dann die Werte für die abgeleitete c1-Spalte, die in der SELECT-Liste definiert ist, berechnet werden.	Mittel
In einer INSERT SELECT-Anweisung mithilfe einer Vereinigung aus unterschiedlichen Datentypen wird jeder UNION-Zweig direkt in den Datentyp der Zielspalte der INSERT-Anweisung konvertiert. Auch wenn die Vereinigung für sich genommen aufgrund inkompatibler Typkonvertierungen einen Fehler erzeugen könnte, bewirkt INSERT SELECT, dass UNION erfolgreich ist, da der Zweig zum Ergebnistyp des UNION-Vorgangs nie konvertiert wird.	Der Ergebnistyp des UNION-Vorgangs wird unabhängig von INSERT SELECT abgeleitet. Jeder UNION-Zweig wird erst in den Ergebnistyp des UNION-Vorgangs und dann in den Datentyp der Zielspalte von INSERT konvertiert. Wenn der UNION-Vorgang inkompatible Typen einschließt, kann die ersten Datentypkonvertierung zu einem Fehler führen. Für die Ausführung mit dem Kompatibilitätsgrad 90 müssen Sie alle inkompatiblen Typvereinigungen beheben, die innerhalb von INSERT SELECT verwendet werden.	Mittel
Einfüge- und Aktualisierungsvorgänge über eine Sicht werden für Sichten, in denen die WITH CHECK OPTION-Klausel angegeben wird, nicht ordnungsgemäß unterstützt, wenn für die Sicht oder eine Sicht, auf die verwiesen wird, die TOP-Klausel verwendet wird.	Einfüge- und Aktualisierungsvorgänge über eine Sicht werden für Sichten nicht unterstützt, in denen WITH CHECK OPTION verwendet wird, wenn für die Sicht oder eine Sicht, auf die verwiesen wird, die TOP-Klausel verwendet wird.	Mittel
Durch die Vereinigung (mithilfe von UNION) einer Spalte variabler Länge und einer Spalte fester Länge wird eine Spalte fester Länge erzeugt.	Durch die Vereinigung (mithilfe von UNION) einer Spalte variabler Länge und einer Spalte fester Länge wird eine Spalte variabler Länge erzeugt.	Mittel
SET XACT_ABORT OFF wird innerhalb eines Triggers ignoriert. Die Option ist immer auf ON festgelegt.	SET XACT_ABORT kann innerhalb eines Triggers auf OFF festgelegt werden.	Mittel
Die FOR BROWSE-Klausel ist in Sichten zulässig (und wird ignoriert).	Die FOR BROWSE-Klausel ist in Sichten nicht zulässig.	Mittel
Domänenfehler werden nicht von ANSI_WARNINGS gesteuert. ARITHABORT-Einstellungen werden berücksichtigt, wenn ANSI_WARNINGS auf OFF festgelegt ist und die ARITHABORT-Einstellung nicht geändert wird.	Domänenfehler werden auch von ANSI_WARNINGS gesteuert und werden als Fehler mit dem Schweregrad 16 behandelt. Wenn ANSI_WARNINGS oder ARITHABORT auf ON festgelegt ist, wird kein NULL-Wert zurückgegeben, sondern ein Fehler ausgelöst. Benutzerskripts, die davon abhängen, dass ARITHABORT auf OFF festgelegt ist, können durch diese Änderung unbrauchbar werden.	Mittel
Wenn eine Passthroughabfrage für eine Remotedatenquelle [OPENROWSET oder OPENQUERY] Spalten mit doppelten Namen erzeugt, werden die doppelten Spaltennamen ignoriert, sofern die Spalten nicht explizit in der Abfrage benannt wurden.	Wenn eine Passthroughabfrage für eine Remotedatenquelle [OPENROWSET oder OPENQUERY] Spalten mit doppelten Namen erzeugt, wird ein Fehler ausgelöst.	Niedrig
Zeichenfolgenkonstanten und varbinary-Konstanten mit mehr als 8000 Zeichen werden als Werte des Typs text, ntext oder image behandelt.	Zeichenfolgenkonstanten und varbinary-Konstanten mit mehr als 8000 Zeichen werden als Werte des Typs varchar(max) (oder nvarchar(max) bzw. varbinary(max)) behandelt. Hierdurch kann sich der Datentyp der Tabelle, die mithilfe von SELECT … INTO erstellt wird, ändern, wenn die SELECT-Liste derartige Ausdrücke enthält.	Niedrig
Vergleiche zwischen numerischen Typen (smallint, tinyint, int, bigint, numeric, decimal, smallmoney, money) werden durchgeführt, indem der Vergleichswert mit der niedrigeren Rangfolgenposition in der Typhierarchie in den Typ mit höherer Rangfolgenposition konvertiert wird.	Werte eines numerischen Typs werden ohne Konvertierung verglichen. Hierdurch wird die Leistung verbessert. Dies kann jedoch zu einigen Verhaltensänderungen führen, insbesondere in Fällen, bei denen die Konvertierung zu einem Überlauf führte.	Niedrig
Integrierte Metadatenfunktionen, die Zeichenfolgenargumente verwenden, schneiden die Eingabe ab, wenn diese mehr als 4000 Zeichen umfasst.	Integrierte Metadatenfunktionen lösen einen Fehler aus, wenn das Abschneiden zu einem Verlust von Zeichen führen würde, die keine Leerzeichen sind.	Niedrig
Die Menge nicht zulässiger Zeichen in einem Bezeichner ohne Anführungszeichen bleibt unverändert.	Der Transact-SQL-Parser unterstützt den Standard Unicode 3.2, wodurch sich die Zeichenklassifizierung für einige internationale Zeichen ändert, die zurzeit in nicht begrenzten Bezeichnern nicht zulässig sind.	Niedrig
SET ANSI_WARNINGS ON setzt die Einstellung SET ARITHABORT OFF im Falle von Gleitkomma-Domänenfehlern, d. h. bei negativen Argumenten für die log()-Funktion, nicht außer Kraft. Wenn ANSI_WARNINGS auf ON, ARITHABORT jedoch auf OFF festgelegt ist, führen Gleitkomma-Domänenfehler nicht zu einer Beendigung der Abfrage.	SET ANSI_WARNINGS ON setzt die Einstellung ARITHABORT OFF vollständig außer Kraft. In diesem Fall führen Gleitkomma-Domänenfehler zu einer Beendigung der Abfrage.	Niedrig
Nicht ganzzahlige Konstanten in der ORDER BY-Klausel sind zulässig (und werden ignoriert).	Nicht ganzzahlige Konstanten in der ORDER BY-Klausel sind nicht zulässig.	Niedrig
Leere SET-Anweisungen (ohne Zuweisung von SET-Optionen) sind zulässig.	Leere SET-Klauseln sind nicht zulässig.	Niedrig
Das IDENTITY-Attribut wird für Spalten, die durch eine abgeleitete Tabelle erstellt werden, nicht ordnungsgemäß abgeleitet.	Das IDENTITY-Attribut wird für Spalten, die durch abgeleitete Tabellen erstellt werden, ordnungsgemäß abgeleitet.	Niedrig
Die Eigenschaft, die die NULL-Zulässigkeit für Ergebnisse arithmetischer Operatoren bestimmt, die auf Daten vom Typ Gleitkommazahl angewendet werden, ist immer so festgelegt, dass NULL-Werte zulässig sind.	Die Eigenschaft, die die NULL-Zulässigkeit für Ergebnisse arithmetischer Operatoren bestimmt, die auf Daten vom Typ Gleitkommazahl angewendet werden, gibt an, dass NULL-Werte unzulässig sind, falls die Eingaben keine NULL-Werte zulassen und ANSI_WARNINGS auf ON festgelegt ist.	Niedrig
In einer INSERT .. SELECT-Anweisung, die den UNION-Operator verwendet, werden alle Datentypen, die durch die einzelnen Resultsets erstellt werden, in den Datentyp der Zieltabelle konvertiert.	In einer INSERT .. SELECT-Anweisung, die den UNION-Operator verwendet, wird der vorherrschende Datentyp der verschiedenen Zweige bestimmt. Die Ergebnisse werden in diesen Typ konvertiert, bevor sie in den Datentyp der Zieltabelle konvertiert werden.	Niedrig
In einer SELECT .. FOR XML-Anweisung werden die Hexadezimalwerte 27 (das Zeichen ') und 22 (das Zeichen ") immer in Entitäten geändert, und zwar auch dann, wenn dies nicht erforderlich ist.	Durch FOR XML werden die Hexadezimalwerte 27 und 22 nur dann in Entitäten geändert, wenn dies erforderlich ist. In den folgenden Situationen erfolgt keine Änderung in Entitäten: Bei Attributinhalten wird der Hexadezimalwert 27 (das Zeichen ') nicht in eine Entität geändert, wenn die Attributwerte durch " begrenzt werden; der Hexadezimalwert 22 (das Zeichen ") wird nicht in eine Entität geändert, wenn die Attributwerte durch ' begrenzt werden. Bei Elementinhalten werden die Hexadezimalwerte nie in Entitäten geändert.	Niedrig
In FOR XML wird der Timestampwert einer ganzen Zahl zugeordnet.	In FOR XML wird der Timestampwert einem Binärwert zugeordnet. Weitere Informationen finden Sie unter FOR XML-Unterstützung für den timestamp-Datentyp.	Hoch (wenn eine timestamp-Spalte verwendet wird), andernfalls Niedrig.
In FOR XML und OPENXML werden in Namen verwendete Unicodezeichen mit hohen Hexadezimalwerten (drei Bytes) mithilfe von acht Positionen dargestellt. So stellt FOR XML beispielsweise den Unicode-Codepunkt U+10000 mithilfe von 8 Positionen folgendermaßen dar: <a_x00010000_ c1="1" />	In FOR XML und OPENXML werden in Namen verwendete Unicode-Zeichen mit hohen Hexadezimalwerten (3 Bytes) mithilfe von 6 Position dargestellt. So stellt FOR XML beispielsweise den Unicode-Codepunkt U+10000 mithilfe von 6 Positionen folgendermaßen dar: <a_x010000_ c1="1" />	Niedrig
In FOR XML sind Zuordnungen abgeleiteter Tabellen im AUTO-Modus nicht sichtbar. Beispiel: `USE AdventureWorks CREATE TABLE Test(id int); INSERT INTO Test VALUES(1); INSERT INTO Test VALUES(2); SELECT * FROM (SELECT a.id AS a, b.id AS b FROM Test a JOIN Test b ON a.id=b.id) Test FOR XML AUTO;` Wenn der Kompatibilitätsgrad für AdventureWorks auf 80 festgelegt wird, wird im vorherigen Beispiel Folgendes erstellt: <a a="1"><b b="1"/></a> <a a="2"><b b="2"/></a>	In FOR XML sind Zuordnungen abgeleiteter Tabellen im AUTO-Modus sichtbar. Wenn der Kompatibilitätsgrad für AdventureWorks auf 90 festgelegt wird, wird im vorherigen Beispiel Folgendes erstellt: <Test a="1" b="1"/> <Test a="2" b="2"/>	Hoch (wenn der FOR XML AUTO-Modus auf Sichten angewendet wird), andernfalls Niedrig
Konvertierungen von Zeichenfolgen in money-Werte unterstützen den umgekehrten Schrägstrich (\) als Währungssymbol nur für die Sprachen Japanisch und Koreanisch.	Der umgekehrte Schrägstrich (\) wird bei allen Konvertierungen von Zeichenfolgen in money-Werte in allen Sprachen angenommen. ISNUMERIC würde TRUE zurückgeben, wenn \ als Währungssymbol verwendet wird. Bei Datenbanken in SQL Server-Versionen, die älter sind als SQL Server 2005, bewirkt dieses neue Verhalten, dass Indizes und berechnete Spalten unterbrochen werden, die von einem ISNUMERIC-Rückgabewert für eine Zeichenfolge mit dem Zeichen \ abhängen und deren Sprache weder Japanisch noch Koreanisch ist.	Tiefstkurs
Bei dem Ergebnis eines arithmetischen Operators sind NULL-Werte immer zulässig, und zwar auch dann, wenn NULL-Werte für die Operanden nicht zulässig sind und ANSI_WARNINGS oder ARITHABORT auf ON festgelegt ist.	Wenn ANSI_WARNINGS oder ARITHABORT auf ON festgelegt ist, sind NULL-Werte für das Ergebnis eines auf Gleitkommazahlen anzuwendenden arithmetischen Operators nicht zulässig, wenn beide Operanden keine NULL-Werte zulassen. Diese Änderung bei der NULL-Zulässigkeit könnte zu Fehlern führen, wenn bcp für das Massenexportieren von Daten im Binärformat aus einer SQL Server 2000-Tabelle mit einer berechneten Spalte verwendet wird, die einen auf Gleitkommazahlen anzuwendenden arithmetischen Operator verwendet, und bcp oder BULK INSERT dann für den Massenimport dieser Daten in eine SQL Server 2005-Tabelle mit derselben Definition verwendet wird. Hinweis Wenn beide Optionen auf OFF festgelegt sind, legt das Database Engine (Datenbankmodul) für das Ergebnis fest, dass es NULL-Werte zulässt. Dies entspricht dem Verhalten in SQL Server 2000.	Tiefstkurs
Bei integrierten Funktionen, die einen nvarchar-Wert als Parameter verwenden, wird der Wert in einen nvarchar(4000)-Wert konvertiert, wenn der bereitgestellte Wert ein varchar-Wert ist. Wenn in SQL Server 2000 ein größerer Wert übergeben wird, wird dieser ohne Hinweis abgeschnitten.	Bei integrierten Funktionen, die einen nvarchar-Wert als Parameter verwenden, wird der Wert ebenfalls in einen nvarchar(4000)-Wert konvertiert, wenn der bereitgestellte Wert ein varchar-Wert ist. Wird jedoch ein größerer Wert übergeben, generiert SQL Server 2008 einen Fehler. Für die Ausführung mit dem Kompatibilitätsgrad 90 müssen Sie benutzerdefinierten Code, der das Abschneiden zu großer Werte voraussetzt, korrigieren.	Tiefstkurs
Bei der Vereinigung einer Zeichenfolge fester Länge (char, binary oder nchar) mit einer Zeichenfolge variabler Länge (varchar, varbinary, nvarchar) wird ein Ergebnis fester Länge zurückgegeben.	Bei der Vereinigung einer Zeichenfolge variabler Länge mit einer Zeichenfolge fester Länge wird eine Zeichenfolge variabler Länge zurückgegeben. Für die Ausführung mit dem Kompatibilitätsgrad 90 müssen Sie alle Elemente (Indizes, Abfragen und berechnete Spalten) korrigieren, die von dem Ergebnistyp der Vereinigung eines Typs variabler Länge mit einem Typ fester Länge abhängen.	Tiefstkurs
Objektnamen, die das Zeichen 0xFFFF enthalten, sind gültige Bezeichner.	Objektnamen, die das Zeichen 0xFFFF enthalten, sind keine gültigen Bezeichner. Der Zugriff darauf ist nicht möglich. Für die Ausführung mit dem Kompatibilitätsgrad 90 müssen Sie Objekte umbenennen, die dieses Zeichen enthalten.	Niedrig
In SELECT ISNUMERIC('<string>') sind eingebettete Kommas innerhalb von <string> signifikant. Beispielsweise gibt die folgende SELECT ISNUMERIC('121212,12')-Abfrage 0 zurück. Dieses Ergebnis zeigt an, dass die Zeichenfolge 121212,12 nicht numerisch ist.	In SELECT ISNUMERIC('<string>') werden eingebettete Kommas innerhalb von <string> ignoriert. Beispielsweise gibt die folgende SELECT ISNUMERIC('121212,12')-Abfrage 1 zurück. Dieses Ergebnis zeigt an, dass die Zeichenfolge 121212,12 numerisch ist.	Niedrig
Ein Doppelpunkt (:) nach einem reservierten Schlüsselwort in einer Transact-SQL-Anweisung wird ignoriert.	Ein Doppelpunkt (:) nach einem reservierten Schlüsselwort in einer Transact-SQL-Anweisung verursacht einen Fehler bei der Anweisung.	Niedrig
Eine GROUP BY-Klausel in einer Unterabfrage, die auf eine Spalte aus der äußeren Abfrage verweist, ist erfolgreich.	Eine GROUP BY-Klausel in einer Unterabfrage, die auf eine Spalte aus der äußeren Abfrage verweist, gibt gemäß dem SQL-Standard einen Fehler zurück.	Niedrig

Unterschiede zwischen niedrigeren Kompatibilitätsgraden und Kompatibilitätsgrad 100

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

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
100	CUBE, MERGE, ROLLUP
90	EXTERNAL, PIVOT, UNPIVOT, REVERT, TABLESAMPLE
80	COLLATE, FUNCTION, OPENXML

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 100 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 Sprachfeatures von Grad 100, 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 OPENXML, das mit dem Kompatibilitätsgrad 80 eingeführt wurde, auch bei Grad 90 und 100 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 AdventureWorks-Datenbank in 90,SQL Server 2005 geändert.

ALTER DATABASE AdventureWorks
SET COMPATIBILITY_LEVEL = 90;
GO

B. Auswirkung des Kompatibilitätsgrades auf ORDER BY (Szenario 1)

Im folgenden Beispiel wird der Unterschied bei der ORDER BY-Bindung für die Kompatibilitätsgrade 80 und 100 veranschaulicht. In dem Beispiel wird die Beispieltabelle SampleTable in der tempdb-Datenbank erstellt.

USE tempdb;
CREATE TABLE SampleTable(c1 int, c2 int);
GO

Beim Kompatibilitätsgrad 90 und höher (Standardeinstellung) generiert die folgende SELECT... ORDER BY-Anweisung einen Fehler, da der Spaltenalias in der AS-Klausel (c1) mehrdeutig ist.

SELECT c1, c2 AS c1
FROM SampleTable
ORDER BY c1;
GO

Nachdem der Kompatibilitätsgrad der Datenbank auf 80 festgelegt wurde, wird dieselbe SELECT... ORDER BY-Anweisung erfolgreich ausgeführt.

ALTER DATABASE tempdb
SET COMPATIBILITY_LEVEL = 80;
GO
SELECT c1, c2 AS c1
FROM SampleTable
ORDER BY c1;
GO

Die folgende SELECT... ORDER BY-Anweisung ist bei beiden Kompatibilitätsgraden funktionsfähig, weil in der AS-Klausel ein eindeutiger Alias angegeben ist.

ALTER DATABASE tempdb
SET COMPATIBILITY_LEVEL = 100;
GO
SELECT c1, c2 AS c3
FROM SampleTable
ORDER BY c1;
GO

ALTER DATABASE tempdb
SET COMPATIBILITY_LEVEL = 80;
GO
SELECT c1, c2 AS c3
FROM SampleTable
ORDER BY c1;
GO

C. Auswirkung des Kompatibilitätsgrades auf ORDER BY (Szenario 2)

Beim Kompatibilitätsgrad 90 und höher (Standardeinstellung) generiert die folgende SELECT...ORDER BY-Anweisung einen Fehler, da der in der ORDER BY-Klausel angegebene Spaltenalias ein Tabellenpräfix enthält.

SELECT c1 AS x
FROM SampleTable
ORDER BY SampleTable.x;
GO

Nachdem der Kompatibilitätsgrad der Datenbank auf 80 festgelegt wurde, wird dieselbe SELECT...ORDER BY-Anweisung erfolgreich ausgeführt.

ALTER DATABASE tempdb
SET COMPATIBILITY_LEVEL = 80;
GO
SELECT c1 AS x
FROM SampleTable
ORDER BY SampleTable.x;
GO

Die folgende SELECT...ORDER BY-Anweisung ist bei beiden Kompatibilitätsgraden funktionsfähig, weil das Tabellenpräfix aus dem in der ORDER BY-Klausel angegebenen Spaltenalias entfernt wurde.

ALTER DATABASE tempdb
SET COMPATIBILITY_LEVEL = 100;
GO
SELECT c1 AS x
FROM SampleTable
ORDER BY x;
GO
ALTER DATABASE tempdb
SET COMPATIBILITY_LEVEL = 80;
GO
SELECT c1 AS x
FROM SampleTable
ORDER BY x;
GO

Änderungsverlauf

Aktualisierter Inhalt
Das Verhalten der XACT_ABORT-Anweisung, wenn sie in einem Trigger angegeben wird, wurde korrigiert. Das Festlegen von XACT_ABORT auf OFF in einem Trigger wird beim Kompatibilitätsgrad 80 ignoriert und beim Kompatibilitätsgrad 90 oder höher zugelassen. Diese Informationen waren in vorherigen Dokumentationen falsch dargestellt.

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)

Konzepte

Datenbank-Kompatibilitätsgrad (Option)

Freigeben über