Fehlerhafte Änderungen an Features des Datenbankmoduls in SQL Server 2005

Artikel
12/15/2008

Aktualisiert: 17. November 2008

In diesem Thema werden die Änderungen an Datenbankmodul in Microsoft SQL Server 2005 beschrieben, die zu Fehlern bei Anwendungen führen können, die auf früheren Versionen von SQL Server basieren.

Client-/Serverkonnektivität

Feature	Beschreibung
Netzwerkprotokolle Banyan VINES Sequenced Packet Protocol (SPP), Multiprotocol, AppleTalk oder NWLink IPX/SPX.	In SQL Server 2005 werden die Netzwerkprotokolle Banyan VINES Sequenced Packet Protocol (SPP), Multiprotocol, AppleTalk und NWLink IPX/SPX nicht unterstützt. Clientanwendungen müssen ein unterstütztes Protokoll verwenden, um eine Verbindung mit SQL Server 2005 herstellen zu können. Wenn ein Alias eingerichtet wird, der eines der nicht unterstützten Protokolle verwendet, muss der Alias so geändert werden, dass er eines der unterstützten Protokolle verwendet. Wenn die Verbindungszeichenfolge einer Anwendung eines der nicht unterstützten Protokolle verwendet oder lädt, indem sie die Eigenschaft NETWORK=DBMSRPCN für RPC, NETWORK=DBMSADSN für Appletalk oder NETWORK=DBMSVINN für Banyan VINES angibt oder indem sie ein explizites Präfix verwendet, wie spx:server\instance für SPX, bv:server für Banyan VINES, adsp:server für AppleTalk oder rpc:server für Multiprotocol, dann müssen Sie die Anwendung so ändern, dass sie eines der unterstützten Protokolle verwendet. Weitere Informationen finden Sie unter Auswählen eines Netzwerkprotokolls.
MDAC	Von früheren MDAC-Versionen als MDAC 2.6 werden keine benannten Instanzen unterstützt. Aktualisieren Sie auf die aktuelle Version von MDAC, um Anwendungsverbindungen mit benannten Instanzen zu ermöglichen.
Winsockproxy	Der Winsockproxy kann nicht mithilfe von SQL Server-Tools konfiguriert werden. Weitere Informationen zum Konfigurieren von Winsockproxy finden Sie in Ihrer Proxyserverdokumentation.

Netzwerkprotokolle Banyan VINES Sequenced Packet Protocol (SPP), Multiprotocol, AppleTalk oder NWLink IPX/SPX.

In SQL Server 2005 werden die Netzwerkprotokolle Banyan VINES Sequenced Packet Protocol (SPP), Multiprotocol, AppleTalk und NWLink IPX/SPX nicht unterstützt. Clientanwendungen müssen ein unterstütztes Protokoll verwenden, um eine Verbindung mit SQL Server 2005 herstellen zu können. Wenn ein Alias eingerichtet wird, der eines der nicht unterstützten Protokolle verwendet, muss der Alias so geändert werden, dass er eines der unterstützten Protokolle verwendet.

Wenn die Verbindungszeichenfolge einer Anwendung eines der nicht unterstützten Protokolle verwendet oder lädt, indem sie die Eigenschaft NETWORK=DBMSRPCN für RPC, NETWORK=DBMSADSN für Appletalk oder NETWORK=DBMSVINN für Banyan VINES angibt oder indem sie ein explizites Präfix verwendet, wie spx:server\instance für SPX, bv:server für Banyan VINES, adsp:server für AppleTalk oder rpc:server für Multiprotocol, dann müssen Sie die Anwendung so ändern, dass sie eines der unterstützten Protokolle verwendet.

Weitere Informationen finden Sie unter Auswählen eines Netzwerkprotokolls.

MDAC

Von früheren MDAC-Versionen als MDAC 2.6 werden keine benannten Instanzen unterstützt. Aktualisieren Sie auf die aktuelle Version von MDAC, um Anwendungsverbindungen mit benannten Instanzen zu ermöglichen.

Winsockproxy

Der Winsockproxy kann nicht mithilfe von SQL Server-Tools konfiguriert werden. Weitere Informationen zum Konfigurieren von Winsockproxy finden Sie in Ihrer Proxyserverdokumentation.

Konfigurationsoptionen

Feature

Beschreibung

AUTO_UPDATE_STATISTICS

Legen Sie AUTO_UPDATE_STATISTICS auf ON fest, bevor Sie Datenbanken aktualisieren. Andernfalls werden die Datenbankstatistiken nicht als Teil des Updates auf SQL Server 2005 aktualisiert. Verweise auf Statistiken aus einer früheren Version von SQL Server können unter Umständen zu nicht optimalen Abfrageplänen führen. Wenn Sie AUTO_UPDATE_STATISTICS auf ON festlegen, werden alle Statistiken aktualisiert, wenn zum ersten Mal auf sie verwiesen wird. Durch das Aktualisieren der Statistiken wird die Wahrscheinlichkeit erhöht, dass beim Ausführen von Abfragen bessere Abfragepläne ausgewählt werden.

ms143179.note(de-de,SQL.90).gif Hinweis:

Nachdem Sie AUTO_UPDATE_STATISTICS auf ON festgelegt haben, kann die Aktualisierung der Statistiken in einigen Fällen die Serverleistung von Abfragen beeinträchtigen, wenn zum ersten Mal auf die Statistiken verwiesen wird.

Zum Festlegen der SET-Option der AUTO_UPDATE_STATISTICS-Datenbank auf ON verwenden Sie die Anweisung ALTER DATABASE. Oder führen Sie zum Aktualisieren der Statistiken in der Datenbank sp_updatestats aus.

Option max server memory

In SQL Server 2000 kann der Pufferpool von SQL Server den mithilfe der Option max server memory festgelegten Grenzwert überschreiten, wenn der physikalische Speicher des Systems verfügbar ist. In SQL Server 2005 darf der Pufferpool den Wert von max server memory nicht überschreiten. Wenn dieses Limit erreicht ist, erzeugt die Abfrage einen Fehler des Typs "Nicht genügend Systemarbeitsspeicher".

Wenn dieser Fehler auftritt und die Option max server memory festgelegt wurde, erhöhen Sie den Wert der Option, oder setzen Sie diesen auf den Standardwert 2147483647. Weitere Informationen finden Sie unter Serverarbeitsspeicher-Optionen.

Option query governor cost limit

Wenn SET GOVERNOR_QUERY_COST_LIMIT oder die Option query governor cost limit von sp_configure angewendet wird, können in einer vorherigen Version von SQL Server ausgeführte Abfragen in SQL Server 2005 möglicherweise nicht ausgeführt werden. Dieses Verhalten tritt aufgrund von Änderungen an der Abfragekostenmodellierung auf.

Aktualisieren Sie die Kostenbeschränkungseinstellungen der Abfragekontrolle für die Verbindung oder Serverinstanz in einen geeigneten Wert, oder legen Sie den Wert auf 0 fest, um keine Beschränkung für den Zeitraum anzugeben, in dem eine Abfrage ausgeführt werden kann.

Datenbanken, Daten- und Protokolldateien

Feature	Beschreibung
Komprimierte Laufwerke	In SQL Server 2005 können keine Datenbanken auf komprimierten Laufwerken erstellt oder aktualisiert werden. Wenn Sie SQL Server 2005 installieren, wählen Sie ein unkomprimiertes Laufwerk für Systemdatenbanken aus, und stellen Sie sicher, dass sich die zu aktualisierenden Datenbanken nicht auf komprimierten Laufwerken befinden. Sie müssen allerdings beachten, dass Sie nach dem Aktualisieren der Datenbank schreibgeschützte Datenbanken und schreibgeschützte sekundäre Dateigruppen in einem komprimierten NTFS-Dateisystem speichern können.
Datendateien	Es ist zusätzlicher Speicherplatz erforderlich, damit die folgenden Änderungen für Datendateien möglich sind: Für Datenbankobjekte und Benutzerberechtigungen werden zusätzliche Systemmetadaten in der PRIMARY-Dateigruppe der einzelnen Benutzerdatenbanken erstellt und verwaltet. In früheren Versionen von SQL Server werden die Berechtigungen, die mit einem Berechtigenden (GRANTOR) oder einer Empfängerliste verknüpft sind, in einer einzigen Zeile als Bitmap gespeichert. In SQL Server 2005 wird das Bitmap auf mehrere Zeilen erweitert. LOB-Spalten (Large Object), die als Datentypen text, ntext oder image definiert sind, erfordern 40 Byte zusätzlichen Speicherplatz pro Spalte. Diese einmalige Speicherplatzerweiterung erfolgt bei der ersten Aktualisierung der jeweiligen LOB-Spalte. Die Zuordnung der Volltext-Dokument-ID (DOCID) wird in der Datendatei statt im Volltextkatalog gespeichert. Wir empfehlen das Festlegen der automatischen Vergrößerung auf ON für alle Benutzerdatendateien, bevor Sie ein Update auf SQL Server 2005 durchführen, um sicherzustellen, dass die Ressourcen Größenerweiterungen beim Update und bei nachfolgenden Produktionsvorgängen verarbeiten können. Nachdem Sie Ihre Arbeitsauslastungen aktualisiert und getestet haben, können Sie die automatische Vergrößerung auf OFF festlegen oder das FILEGROWTH-Inkrement entsprechend anpassen. Weitere Informationen finden Sie unter ALTER DATABASE (Transact-SQL).
Datenbank-Kompatibilitätsmodus	Wenn eine Datenbank von einer früheren SQL Server-Version auf SQL Server 2005 aktualisiert wird, behält die Datenbank den bestehenden Kompatibilitätsgrad bei. Wenn Sie den Kompatibilitätsmodus nach dem Update auf 90 ändern, können die Unterschiede im Kompatibilitätsmodus die Anwendungen beeinträchtigen. Weitere Informationen zu diesen Unterschieden finden Sie unter sp_dbcmptlevel (Transact-SQL).
Datenbank-ID 32767	In SQL Server 2005 ist diese Datenbank-ID reserviert. Trennen Sie die Datenbank vor dem Aktualisieren.
Dateigruppen	Die Dateigruppen müssen für alle Datenbanken in der Instanz von SQL Server auf READ_WRITE festgelegt werden, bevor Sie ein Update auf SQL Server 2005 durchführen. Sie können eine Dateigruppe mithilfe von ALTER DATABASE auf READ_WRITE festlegen.
Protokolldateien	In SQL Server 2005 ist zusätzlicher Speicherplatz für Transaktionsprotokolldateien erforderlich. Während der Rollbackphase einer Wiederherstellung nach einem Systemabsturz ermöglicht SQL Server 2005 den Benutzern den Zugriff auf die Datenbank. Dies ist möglich, weil die Transaktionen, für die zum Zeitpunkt des Systemabsturzes noch kein Commit durchgeführt wurde, alle Sperren erneut abrufen, die sie vor dem Crash aufrechterhalten haben. Wenn für die Transaktionen Rollbacks ausgeführt werden, schützen ihre Sperren sie vor Störungen durch Benutzer. Diese zusätzlichen Sperrinformationen müssen im Transaktionsprotokoll verwaltet werden. Wir empfehlen das Festlegen der automatischen Vergrößerung auf ON für alle Benutzerprotokolldateien, bevor Sie ein Update auf SQL Server 2005 durchführen, um sicherzustellen, dass die Ressourcen Größenerweiterungen beim Update und bei nachfolgenden Produktionsvorgängen verarbeiten können. Nachdem Sie Ihre Arbeitsauslastungen aktualisiert und getestet haben, können Sie die automatische Vergrößerung auf OFF festlegen oder das FILEGROWTH-Inkrement entsprechend anpassen. Weitere Informationen finden Sie unter ALTER DATABASE (Transact-SQL).
model-Datenbank	In SQL Server 2005 beinhaltet die model-Datenbank die folgenden Änderungen: Die Mindestgröße ist erweitert. Der Kompatibilitätsgrad ist auf 90 festgelegt. Die Datenbankoption PAGE_VERIFY ist auf CHECKSUM festgelegt.
tempdb-Datenbank	Für die tempdb-Daten und -Protokolldateien ist in SQL Server 2005 zusätzlicher Speicherplatz erforderlich. Um sicherzustellen, dass die Ressourcen beim Update und bei nachfolgenden Produktionsvorgängen Größenerweiterungen verarbeiten können, wird empfohlen, die automatische Vergrößerung für alle tempdb-Daten und -Protokolldateien auf ON zu setzen, bevor Sie ein Update auf SQL Server 2005 durchführen. Nachdem Sie Ihre Arbeitsauslastungen aktualisiert und getestet haben, können Sie die automatische Vergrößerung auf OFF festlegen oder das FILEGROWTH-Inkrement entsprechend anpassen. Weitere Informationen finden Sie unter Problembehandlung bei unzureichendem Speicherplatz in tempdb.

Features

Feature

Beschreibung

Erweiterte gespeicherte Prozeduren

Erweiterte gespeicherte Prozeduren, die vorher ohne den vollständigen Pfad für den DLL-Namen registriert wurden, sind möglicherweise nach einem Update auf SQL Server 2005 nicht funktionsfähig. Dies liegt daran, dass dem neuen Pfad während des Aktualisierungsvorgangs nicht das alte BINN-Verzeichnis hinzugefügt wird. SQL Server kann die erweiterten gespeicherten Prozeduren möglicherweise nicht lokalisieren.

Bevor Sie ein Update auf SQL Server 2005 durchführen, führen Sie die folgenden Schritte für jede erweiterte gespeicherte Prozedur aus, die nicht mit einem vollständigen Pfadnamen registriert ist:

Führen Sie zum Entfernen der erweiterten gespeicherten Prozedur sp_dropextendedproc aus.
Führen Sie zum Registrieren der erweiterten gespeicherten Prozedur mit dem vollständigen Pfadnamen sp_addextendedproc aus.

Protokollversand

Der Protokollversand in früheren Versionen von SQL Server ist mit dem Protokollversand in SQL Server 2005 nicht kompatibel und kann nicht direkt aktualisiert werden. Nach dem Update auf SQL Server 2005 müssen Sie den Protokollversand mit SQL Server Management Studio oder mithilfe gespeicherter Prozeduren neu konfigurieren. Weitere Informationen finden Sie unter Migrieren einer Protokollversandkonfiguration für SQL Server 2000 nach SQL Server 2005.

Dienstprogramm osql

Das Dienstprogramm osql bietet keine Unterstützung für die Befehle ED und !!. Entfernen Sie Verweise auf die Befehle ED und !! aus Ihren Skripts. Wenn Sie die Befehle ED und !! verwenden möchten, verwenden Sie stattdessen das Dienstprogramm sqlcmd.

SQL-DMO-WMI-Anbieter

Der SQL-DMO-WMI-Anbieter wurde eingestellt und ist nicht verfügbar.

SQL Mail

SQL Server unterstützt ein SQL Mail-Update von SQL Server 7.0 oder SQL Server 2000. Für SQL Server 2005 ist allerdings Microsoft Outlook 2002 oder höher als Mailclient erforderlich.

ms143179.note(de-de,SQL.90).gif Hinweis:

Dieses Feature wird in einer zukünftigen Version von Microsoft SQL Server entfernt. Verwenden Sie dieses Feature beim Entwickeln neuer Anwendungen nicht, und planen Sie das Ändern von Anwendungen, in denen es zurzeit verwendet wird. Versenden Sie E-Mail-Nachrichten aus SQL Server 2005 mit Datenbank-E-Mail.

SQL Mail

Wenn ein mithilfe der SQL Server-Authentifizierung verbundener Client versucht, SQL Mail mit einem Anhang zu senden, kann SQL Server keinen entsprechenden Sicherheitskontext festlegen und gibt einen Fehler zurück. Sie können dieses Problem umgehen, indem Sie die Windows-Authentifizierung verwenden.

SQL-Namespace-API (SQL-NS)

Die SQL-Namespace-API (SQL-NS) wurde eingestellt und ist nicht verfügbar.

Ablaufverfolgungsflags

In SQL Server 2000 wird ein Ablaufverfolgungsflag, das in Sitzung A festgelegt wurde, nicht automatisch in einer bereits bestehenden Sitzung B wirksam. Stattdessen wird das Ablaufverfolgungsflag erst wirksam, wenn zum ersten Mal ein Ablaufverfolgungsflag in Sitzung B festgelegt wird. Dieses Verhalten ist in SQL Server 2000 nicht deterministisch und in SQL Server 2005 deterministisch. In SQL Server 2005 werden globale Ablaufverfolgungsflags, die in Sitzung A festgelegt werden, sofort in anderen gleichzeitigen Sitzungen festgelegt.

Darüber hinaus können Ablaufverfolgungsflags in SQL Server 2005 als lokal oder global festgelegt werden, indem Sie ein zusätzliches Argument in der Anweisung DBCC TRACEON verwenden. Wenn Sie das zweite Argument nicht angeben, ist der Standardwert in SQL Server 2005 lokal. Im Gegensatz dazu ist der Standardwert in SQL Server 2000 global.

Weitere Informationen finden Sie unter Ablaufverfolgungsflags (Transact-SQL).

Ablaufverfolgungsflags

Einige Ablaufverfolgungsflags von SQL Server 2000 sind in SQL Server 2005 nicht verfügbar. Außerdem haben einige Ablaufverfolgungsflags in SQL Server 2005 eine andere Funktionalität. Sie sollten alle Ablaufverfolgungsflags deaktivieren, bevor Sie ein Update auf SQL Server 2005 durchführen. Nach dem Update müssen Sie sicherstellen, dass sich die Funktionalität des Ablaufverfolgungsflags nicht geändert hat. Überprüfen Sie auch, ob das Ablaufverfolgungsflag immer noch erforderlich ist, bevor Sie ein Ablaufverfolgungsflag erneut aktivieren.

Trigger

In SQL Server 2005 können DDL-Anweisungen (Data Definition Language, Datendefinitionssprache) wie CREATE INDEX für die inserted- und deleted-Tabellen in DML-Triggern nicht ausgeführt werden. In früheren Versionen von SQL Server können einige DDL-Anweisungen für die Tabellen inserted und deleted ausgeführt werden. Weitere Informationen finden Sie unter Verwenden der Tabellen inserted und deleted.

Doppelte Indexnamen

In SQL Server 2005 sind doppelte Indexnamen für Tabellen oder Sichten nicht zulässig. Bevor Sie ein Update durchführen, müssen Sie die Indizes umbenennen, um Duplikate zu entfernen.

Suchen Sie die doppelten Indizes durch Ausführen der folgenden Abfrage:

SELECT DISTINCT OBJECT_NAME(o.id), name
FROM sysindexes as o
WHERE EXISTS 
    (SELECT name FROM sysindexes  as i
      WHERE i.id = o.id
      AND i.name = o.name and i.indid < o.indid);

Ändern Sie einen der Indexnamen mithilfe von sp_rename. Da die Indexnamen identisch sind, können Sie nicht bestimmen, welcher Index umbenannt wird. Durch diesen Schritt können Sie die Indizes unterscheiden.
```
EXEC sp_rename N'table_name.index_name', N'new_index_name, N'INDEX'
```

Überprüfen Sie durch Ausführen der folgenden Abfrage, welcher Index umbenannt wurde. Die folgende Abfrage gibt alle Indizes zurück, einschließlich der Schlüsselspaltennamen für die angegebene Tabelle oder Sicht:

SELECT i.name AS IndexName, c.name AS ColumnName, ik.colid, ik.keyno
FROM sysindexes i
JOIN sysindexkeys ik ON i.id = ik.id and i.indid = ik.indid 
JOIN syscolumns c ON c.id = ik.id and ik.colid = c.colid
WHERE i.id = OBJECT_ID('table_or_view_name')

Verwenden Sie sp_rename bei Bedarf erneut, um die Indexnamen zu korrigieren.

Objektnamen

In SQL Server 2005 können Sie das Zeichen 0xFFFF in Objektnamen nicht verwenden. Wenn ein Objektname dieses Unicode-Zeichen enthält, können Sie auf dieses Objekt nicht zugreifen, wenn der Kompatibilitätsgrad der Datenbank 90 ist. Benennen Sie Objekte um, die dieses Zeichen enthalten.

Abstimmen von Tabellenvariablen und Spaltensortierung

In SQL Server 2000 werden die in den Tabellenvariablen definierten Spalten implizit an die Sortierung der Datenbank tempdb angepasst. In SQL Server 2005 werden die in den Tabellenvariablen definierten Spalten implizit an die Sortierung der aktuellen Datenbank angepasst. Abfragen, die vom Verhalten von SQL Server 2000 abhängig sind, geben möglicherweise unerwartete Ergebnisse zurück, z. B. eine andere Anzahl oder Reihenfolge der zurückgegebenen Zeilen.

So werden beispielsweise für den Übereinstimmungsvergleich der Spalten c1 und c2 in der WHERE-Klausel der folgenden SELECT-Anweisung möglicherweise weniger oder mehr Zeilen zurückgegeben, wenn die Sortierung der Datenbank TestDB anstelle der tempdb-Sortierung verwendet wird. So würden beispielsweise die Werte "Name" und "name" als identisch ausgewertet werden, wenn bei der Sortierung die Groß-/Kleinschreibung nicht beachtet wird. Dies gilt jedoch nicht, wenn die Groß-/Kleinschreibung bei der Sortierung beachtet wird.

CREATE DATABASE TestDB COLLATE Estonian_CS_AI;
GO
USE TestDB;
DECLARE @TempTable table (c1 varchar(10), c2 varchar(10);
SELECT * FROM @TempTable WHERE c1 = c2;

Um statt der aktuellen Sortierreihenfolge anhand einer Tabellenvariable eine andere Sortierung zu verwenden, geben Sie die Sortierung in der Definition der Spalten in der DECLARE-Anweisung oder in der Abfrage an, die auf die Spalten verweist. Im folgenden Beispiel finden Sie beide Methoden.

USE TestDB;
DECLARE @TempTable table (c1 varchar(10)COLLATE Latin1_General_CS_AS, c2 varchar(10)COLLATE Latin1_General_CS_AS);
SELECT * FROM @TempTable WHERE c1 = c2;
GO
-- or

DECLARE @TempTable table (c1 varchar(10), c2 varchar(10));
SELECT * FROM @TempTable WHERE c1 = c2 COLLATE Latin1_General_CS_AS;
GO

Indizierte Sichten

Feature Beschreibung

Feature	Beschreibung
Funktionsdeterminismus	Die folgenden Funktionsausdrücke werden in SQL Server 2005 als nicht deterministisch erachtet und können daher das Erstellen indizierter Sichten beeinträchtigen: Verweise auf Zeichenfolgenliterale, die implizit in datetime und smalldatetime konvertiert werden. Implizite Konvertierung von Nicht-Unicode-Zeichendaten zwischen Sortierungen. Ausdrücke, die eine implizite Konvertierung von Zeichenfolgen in datetime oder smalldatetime aufweisen, werden in SQL Server 2005 als nicht deterministisch erachtet, wenn der Kompatibilitätsgrad nicht auf 80 oder niedriger festgelegt ist. Ursache hierfür ist, dass die Ergebnisse von den LANGUAGE- und DATEFORMAT-Einstellungen der Serversitzung abhängig sind. Die Ergebnisse des Ausdrucks `CONVERT (datetime, '30 listopad 1996', 113)` sind beispielsweise von der LANGUAGE-Einstellung abhängig, weil die Zeichenfolge '`listopad`' für verschiedene Monate in unterschiedlichen Sprachen steht. In ähnlicher Weise interpretiert SQL Server in dem Ausdruck `DATEADD(mm,3,'2000-12-01')` die Zeichenfolge `'2000-12-01'` basierend auf der DATEFORMAT-Einstellung. Die implizite Konvertierung von Nicht-Unicode-Zeichendaten zwischen Sortierungen wird ebenso als nicht deterministisch bezeichnet, es sei denn, der Kompatibilitätsgrad ist auf 80 oder niedriger festgelegt. Das Erstellen von Indizes oder Sichten, die diese Ausdrücke enthalten, ist bei einem Datenbankkompatibilitätsgrad von 90 nicht zulässig. Obwohl vorhandene Sichten, die diese Ausdrücke aus einer aktualisierten Datenbank enthalten, verwaltet werden können, werden diese vom Abfrageoptimierer für Abfragepläne der Kompatibilitätsgrade 80 oder 90 nicht berücksichtigt. Weitere Informationen zum Festlegen des Kompatibilitätsgrads finden Sie unter sp_dbcmptlevel (Transact-SQL). Bei der Definition indizierter Sichten in SQL Server 2005 sollten Sie das Literal explizit in den gewünschten Datentyp konvertieren, indem Sie ein deterministisches Datumsformat verwenden. Eine Liste der deterministischen Datumsformate finden Sie unter CAST und CONVERT (Transact-SQL). Wenn Sie in vorhandenen indizierten Sichten, die auf SQL Server 2005 aktualisiert wurden, implizite Konvertierungen von Zeichenfolgen in Datumsangaben verwenden, sollten Sie sicherstellen, dass die LANGUAGE- und DATEFORMAT-Einstellungen in Ihren Datenbanken und Anwendungen konsistent sind, um eine mögliche Beschädigung der indizierten Sichten zu vermeiden.
IGNORE_DUP_KEY	Wenn Sie einen eindeutigen gruppierten Index für eine Sicht in SQL Server 2005 erstellen, muss die Option IGNORE_DUP_KEY auf OFF festgelegt sein. Dies ist die Standardeinstellung. Das Festlegen von IGNORE_DUP_KEY auf ON könnte zu einer Beschädigung der indizierten Sicht führen. Löschen Sie den gruppierten Index für die Sicht, und erstellen Sie ihn ohne Angabe der Option IGNORE_DUP_KEY erneut.
Abfragehinweise	Abfragehinweise in den Definitionen indizierter Sichten werden bei einem Kompatibilitätsgrad von 80 ignoriert. Dadurch verhalten sich einige Anwendungen zwischen den Kompatibilitätsgraden 80 und 90 möglicherweise unterschiedlich. Weitere Informationen finden Sie unter Entwerfen von indizierten Sichten, Erstellen von indizierten Sichten und Abfragehinweis (Transact-SQL).

Funktionsdeterminismus

Die folgenden Funktionsausdrücke werden in SQL Server 2005 als nicht deterministisch erachtet und können daher das Erstellen indizierter Sichten beeinträchtigen:

Verweise auf Zeichenfolgenliterale, die implizit in datetime und smalldatetime konvertiert werden.
Implizite Konvertierung von Nicht-Unicode-Zeichendaten zwischen Sortierungen.

Ausdrücke, die eine implizite Konvertierung von Zeichenfolgen in datetime oder smalldatetime aufweisen, werden in SQL Server 2005 als nicht deterministisch erachtet, wenn der Kompatibilitätsgrad nicht auf 80 oder niedriger festgelegt ist. Ursache hierfür ist, dass die Ergebnisse von den LANGUAGE- und DATEFORMAT-Einstellungen der Serversitzung abhängig sind. Die Ergebnisse des Ausdrucks CONVERT (datetime, '30 listopad 1996', 113) sind beispielsweise von der LANGUAGE-Einstellung abhängig, weil die Zeichenfolge 'listopad' für verschiedene Monate in unterschiedlichen Sprachen steht. In ähnlicher Weise interpretiert SQL Server in dem Ausdruck DATEADD(mm,3,'2000-12-01') die Zeichenfolge '2000-12-01' basierend auf der DATEFORMAT-Einstellung.

Die implizite Konvertierung von Nicht-Unicode-Zeichendaten zwischen Sortierungen wird ebenso als nicht deterministisch bezeichnet, es sei denn, der Kompatibilitätsgrad ist auf 80 oder niedriger festgelegt.

Das Erstellen von Indizes oder Sichten, die diese Ausdrücke enthalten, ist bei einem Datenbankkompatibilitätsgrad von 90 nicht zulässig. Obwohl vorhandene Sichten, die diese Ausdrücke aus einer aktualisierten Datenbank enthalten, verwaltet werden können, werden diese vom Abfrageoptimierer für Abfragepläne der Kompatibilitätsgrade 80 oder 90 nicht berücksichtigt. Weitere Informationen zum Festlegen des Kompatibilitätsgrads finden Sie unter sp_dbcmptlevel (Transact-SQL).

Bei der Definition indizierter Sichten in SQL Server 2005 sollten Sie das Literal explizit in den gewünschten Datentyp konvertieren, indem Sie ein deterministisches Datumsformat verwenden. Eine Liste der deterministischen Datumsformate finden Sie unter CAST und CONVERT (Transact-SQL).

Wenn Sie in vorhandenen indizierten Sichten, die auf SQL Server 2005 aktualisiert wurden, implizite Konvertierungen von Zeichenfolgen in Datumsangaben verwenden, sollten Sie sicherstellen, dass die LANGUAGE- und DATEFORMAT-Einstellungen in Ihren Datenbanken und Anwendungen konsistent sind, um eine mögliche Beschädigung der indizierten Sichten zu vermeiden.

IGNORE_DUP_KEY

Wenn Sie einen eindeutigen gruppierten Index für eine Sicht in SQL Server 2005 erstellen, muss die Option IGNORE_DUP_KEY auf OFF festgelegt sein. Dies ist die Standardeinstellung. Das Festlegen von IGNORE_DUP_KEY auf ON könnte zu einer Beschädigung der indizierten Sicht führen.

Löschen Sie den gruppierten Index für die Sicht, und erstellen Sie ihn ohne Angabe der Option IGNORE_DUP_KEY erneut.

Abfragehinweise

Abfragehinweise in den Definitionen indizierter Sichten werden bei einem Kompatibilitätsgrad von 80 ignoriert. Dadurch verhalten sich einige Anwendungen zwischen den Kompatibilitätsgraden 80 und 90 möglicherweise unterschiedlich. Weitere Informationen finden Sie unter Entwerfen von indizierten Sichten, Erstellen von indizierten Sichten und Abfragehinweis (Transact-SQL).

Sicherheit

Feature	Beschreibung
Anmeldenamen	Die folgenden Namen von festen Serverrollen sind in SQL Server 2005 reserviert und können nicht als benutzerdefinierte Anmeldenamen verwendet werden: sysadmin serveradmin setupadmin securityadmin processadmin dbcreator diskadmin bulkadmin Bevor Sie ein Update auf SQL Server 2005 durchführen, gehen Sie wie folgt vor: Zeichnen Sie die Sicherheits-IDs (SIDs) der Anmeldungen durch Ausführen der folgenden Anweisung auf: `SELECT name, sid FROM master.dbo.syslogins WHERE name IN('sysadmin', 'serveradmin','setupadmin', 'securityadmin','processadmin', 'dbcreator','diskadmin', 'bulkadmin')` Löschen Sie die Anmeldungen. Zum Erstellen neuer Anmeldungen verwenden Sie die Systemprozedur sp_addlogin. Geben Sie im @sid-Parameter für die jeweilige Anmeldung die in Schritt 1 zurückgegebene SID an.
Anmelde-SID (SID)	In SQL Server 2005 sind doppelte Sicherheits-IDs (SIDs) nicht zulässig. Entfernen Sie eine der Anmeldungen und die damit verknüpften Benutzer vor dem Update.
Zuordnung der Remoteanmeldung	In früheren Versionen von SQL Server können Anmeldungen von Remoteinstanzen von SQL Server mithilfe der gespeicherten Systemprozedur sp_remoteoption als vertrauenswürdig markiert werden. In SQL Server 2005 wird diese Methode für das Kennzeichnen von Remoteanmeldungen nicht unterstützt. Nach dem Update auf SQL Server 2005 sind Remoteanmeldungen nicht mehr als vertrauenswürdig markiert. Zum Einrichten und Verwalten von Remoteanmeldungen verwenden Sie Verbindungsserver und gespeicherte Prozeduren von Verbindungsservern. Weitere Informationen finden Sie unter Verbindungsserver.
SQL Server 6.5-Anmeldungen	In SQL Server 6.5 werden Kennworthashes in einem Format gespeichert, das nicht mehr unterstützt wird. Das alte Kennwort kann nicht direkt auf SQL Server 2005 aktualisiert werden. Sie müssen das entsprechende Kennwort neu festlegen, um diese Anmeldung zu aktivieren. Sie können das Kennwort mithilfe von ALTER LOGIN neu festlegen: `ALTER LOGIN <login name> WITH PASSWORD = '<new password>' MUST_CHANGE` Das neue Kennwort wird auf die Erfüllung der Richtlinie für die Kennwortkomplexität Ihres Systems überprüft, es sei denn, die Richtlinienüberprüfung ist deaktiviert. Es wird empfohlen, komplexe Kennwörter zu verwenden und die Richtlinienüberprüfung nicht zu deaktivieren. Durch die Option MUST_CHANGE wird der Benutzer zum Auswählen eines neuen Kennwortes gezwungen. Dies wird empfohlen, ist aber nicht erforderlich. Sie können ruhende SQL Server 6.5-Anmeldungen mithilfe der folgenden Abfrage identifizieren: `SELECT * FROM sysxlogins WHERE (xstatus & 2048) = 2048; GO`
Benutzername sys	Der Name sys ist in SQL Server 2005 reserviert und kann nicht als Benutzername verwendet werden. Benennen Sie den Benutzer um, bevor Sie ein Update auf SQL Server 2005 durchführen. Wenn der Benutzer nicht umbenannt wird, ist die Datenbank nach dem Updatevorgang fehlerverdächtig und nicht verfügbar, bis die Datenbank online geschaltet wird. Prozedur vor dem Update Bevor Sie ein Update auf SQL Server 2005 durchführen, müssen Sie für alle Datenbanken, die einen Benutzer sys enthalten, folgende Schritte durchführen: Erstellen Sie einen neuen Benutzer. Zeigen Sie mithilfe der folgenden Anweisungen alle Berechtigungen an, die vom Benutzer sys und für den Benutzer sys erteilt wurden. `-- Return permissions granted by user sys. SELECT * FROM sysprotects WHERE grantor = USER_ID('sys') -- Return permissions granted to user sys. SELECT * FROM sysprotects WHERE uid = USER_ID('sys')` Übertragen Sie den Besitz aller Objekte, die sich im Besitz von sys befinden, mithilfe von sp_changeobjectowner auf den neuen Benutzer. Löschen Sie den Benutzer sys. Stellen Sie die in Schritt 2 aufgezeichneten ursprünglichen Berechtigungen mithilfe der AS new_user-Klausel der GRANT-Anweisung wieder her. Ändern Sie die Skripts so, dass sie auf den neuen Benutzer verweisen. Prozedur nach dem Update Wenn der Benutzer sys vor dem Update nicht umbenannt wurde, führen Sie die folgenden Schritte aus: Führen Sie die Anweisung `ALTER DATABASE db_name SET ONLINE` aus. Die Datenbank befindet sich im SINGLE_USER-Modus. Führen Sie alle Schritte im Abschnitt "Prozedur vor dem Update" aus. Führen Sie die Anweisung `ALTER DATABASE db_name SET MULTI_USER` aus.

Systemobjekte und Systemmetadaten

Feature	Beschreibung
INFORMATION_SCHEMA.COLUMNS	In SQL Server 2005 ist die Spalte ORDINAL_POSITION der Sicht INFORMATION_SCHEMA.COLUMNS nicht kompatibel mit dem Bitmuster, das von der COLUMNS_UPDATED-Funktion zurückgegeben wird. Für ein mit COLUMNS_UPDATED kompatibles Bitmuster verweisen Sie wie im folgenden Beispiel veranschaulicht auf die ColumnID-Eigenschaft der COLUMNPROPERTY-Systemfunktion, wenn Sie die INFORMATION_SCHEMA.COLUMNS-Sicht abfragen: `SELECT TABLE_NAME, COLUMN_NAME, COLUMNPROPERTY(OBJECT_ID(TABLE_SCHEMA + '.' + TABLE_NAME), COLUMN_NAME, 'ColumnID') AS COLUMN_ID FROM AdventureWorks.INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = 'Contact';`
INFORMATION_SCHEMA.SCHEMATA	In früheren Versionen von SQL Server wurden in der Sicht INFORMATION_SCHEMA.SCHEMATA alle Datenbanken einer Instanz von SQL Server zurückgegeben. In SQL Server 2005 gibt die Sicht alle Schemas in einer Datenbank zurück. Dieses Verhalten entspricht dem SQL-Standard. Weitere Informationen finden Sie unter SCHEMATA (Transact-SQL).
Mit dem Wert '%SCHEMA' übereinstimmende INFORMATION_SCHEMA-Spaltennamen	In früheren Versionen von SQL Server geben INFORMATION_SCHEMA-Spaltennamen, die mit dem Wert "%SCHEMA" übereinstimmen, den Namen des Benutzers zurück. In SQL Server 2005 geben diese Spalten den Schemanamen zurück. Wenn eine Datenbank auf SQL Server 2005 aktualisiert wird, stimmt der Schemaname immer mit dem Benutzernamen überein, und keine Anwendungen, die auf diese Spalten verweisen, erzeugen einen Fehler. Benutzer, die SQL Server 2005-Features zur Trennung des Benutzerschemas in ihren Datenbanken implementieren, sollten allerdings beachten, dass ihre Anwendungen möglicherweise Fehler erzeugen, wenn die erwarteten Daten einen Benutzernamen und keinen Schemanamen darstellen. Weitere Informationen finden Sie unter Trennung von Benutzer und Schema.
sp_helptrigger	In SQL Server 2005 wird dem Resultset, das von der gespeicherten Systemprozedur sp_helptrigger zurückgegeben wird, als letzte Spalte trigger_schema hinzugefügt. Überprüfen Sie die Verwendung von sp_helptrigger in Anwendungen. Sie müssen Ihre Anwendungen möglicherweise ändern, damit die zusätzliche Spalte hinzugefügt werden kann. Alternativ können Sie auch die sys.triggers-Katalogsicht verwenden.
syslockinfo und sp_lock	In SQL Server 2000 geben die Spalten rsc_objid und rsc_indid in syslockinfo sowie die Spalten objid und indid in sp_lock einheitlich die Objekt- und Index-ID zurück. In SQL Server 2005 kann der Wert 0 (null) zurückgegeben werden. In SQL Server 2000 geben syslockinfo und sp_lock für eine bestimmte LOCK-Ressource einer einzelnen Transaktion höchstens zwei Zeilen zurück. Wenn die Sperrenpartitionierung aktiviert ist, werden in SQL Server 2005 möglicherweise mehrere Zeilen für dieselbe Ressource zurückgegeben, die unter einer Transaktion ausgeführt wird. Es können bis zu N + 1 Zeilen zurückgegeben werden, wobei N für die Anzahl der CPUs steht. In SQL Server 2005 können außerdem die GRANTED- und WAITING-Anforderungen für dieselbe Ressource angezeigt werden. In SQL Server 2000 können diese Anforderungen für dieselbe Ressource nicht angezeigt werden. Weitere Informationen finden Sie unter sp_lock (Transact-SQL) und sys.syslockinfo (Transact-SQL).
Anpassen der Sortierung von Systemobjektnamen und Systemtypnamen	In früheren Versionen von SQL Server werden die Systemobjektnamen und Systemtypnamen an die Sortierung der master-Datenbank angepasst. In SQL Server 2005 werden Systemobjektnamen und Systemtypnamen automatisch umgewandelt, damit sie der Sortierung der aktuellen Datenbank entsprechen. Wenn Verweise auf diese Objekte in einem Skript oder in Anwendungen nicht mit ihrer Darstellung im Katalog übereinstimmen und die aktuelle Datenbank eine Sortierung mit Unterscheidung nach Groß-/Kleinschreibung aufweist, erzeugt das Skript oder die Anwendung möglicherweise einen Fehler. Die `EXEC SP`_`heLP`-Anweisung erzeugt beispielsweise einen Fehler, wenn die aktuelle Datenbank eine Sortierung mit Unterscheidung nach Groß-/Kleinschreibung aufweist.
Ändern von Systemobjekten	Das direkte Aktualisieren von Systemkatalogen ist in SQL Server 2005 nicht zulässig. Jeder Versuch generiert die folgende Fehlermeldung: "Server: Meldung 259, Ebene 16, Status 1, Zeile 1" "Ad-hoc-Aktualisierungen von Systemkatalogen sind nicht zulässig." Ändern Sie Ihre SQL-Skripts so, dass sie offizielle und dokumentierte APIs verwenden. Verwenden Sie beispielsweise ALTER DATABASE database_name SET EMERGENCY, anstatt eine UPDATE-Anweisung für die sysdatabases-Systemtabelle auszuführen.
Entfernen von Systemobjekten	Anweisungen wie DROP TABLE, DROP PROCEDURE und sp_dropextendedproc können nicht zum Entfernen von Systemobjekten verwendet werden, da diese Objekte in der schreibgeschützten Ressourcendatenbank bereitgestellt werden. Entfernen Sie alle Anweisungen, mit denen Systemobjekte aus Ihren Anwendungen gelöscht werden. Ändern Sie Ihre Anwendungen, sodass sie EXECUTE-Berechtigungen für Systemobjekte aufheben oder verweigern. Alternativ können Sie auch eines der Tools zur Oberflächenkonfiguration in SQL Server 2005 verwenden, um einige dieser Objekte zu deaktivieren. Die erweiterte gespeicherte Prozedur xp_cmdshell kann beispielsweise mithilfe eines der Tools für die Oberflächenkonfiguration deaktiviert oder aktiviert werden.
sysperfinfo	In SQL Server 2005 gibt sysperfinfo einen bigint-Wert für die Spalte cntr_value zurück. Ändern Sie die Anwendungen, die sysperfinfo verwenden, um sicherzustellen, dass diese die bigint-Werte der Spalte cntr_value aufnehmen können. In SQL Server 2005 handelt es sich bei sysperfinfo um eine Kompatibilitätssicht. Sie sollten stattdessen die dynamische Verwaltungssicht sys.dm_os_performance_counters verwenden.
Mithilfe von 'dbo' als Suchkriterium abgefragte Systemtabellen	In früheren Versionen von SQL Server sind Systemobjekte im Besitz von dbo und befinden sich in der master-Datenbank. In SQL Server 2005 sind Systemobjekte im Besitz von sys und werden aufgrund dessen in jeder Datenbank angezeigt. Anweisungen, die Systemtabellen abfragen und den Benutzer dbo als Suchkriterium aufweisen, erzeugen einen Fehler.

Transact-SQL

Feature	Beschreibung
@@VERSION	SQL Server 2005 gibt ausführlichere Informationen als SQL Server 2000 zurück, und zwar im Format major.minor.build.incremental-build.
CREATE STATISTICS	Das Angeben von WITH ROWS in CREATE STATISTICS-Anweisungen wird in SQL Server 2005 nicht unterstützt. Ändern Sie CREATE STATISTICS-Anweisungen, die WITH ROWS enthalten, indem Sie SAMPLE number zwischen WITH und ROWS angeben, oder indem Sie andere Optionen angeben, die der dokumentierten Syntax entsprechen.
DISK INIT	Die DISK INIT-Anweisung, die in früheren Versionen von SQL Server verwendet wurde, um Datenbank- oder Transaktionsprotokollmedien zu erstellen, wurde in SQL Server 2005 entfernt. Ersetzen Sie alle Vorkommnisse dieser Anweisung durch entsprechende CREATE DATABASE- oder ALTER DATABASE-Anweisungen.
UNION in einer INSERT INTO...SELECT-Anweisung	Wenn sich ein UNION-Operator in einer INSERT-Anweisung befindet, wandelt SQL Server 2005 den Datentyp der einzelnen UNION-Vorgänge entsprechend den Regeln der Datentypkonvertierung unabhängig voneinander um. Anschließend werden die Datentypen des Endergebnisses des UNION-Vorgangs in die entsprechenden Spalten der Tabelle umgewandelt, die das Ziel des INSERT-Vorgangs ist. Diese Verhaltensänderung kann in Ihren Anwendungen zu Fehlern beim Umwandeln von Datentypen führen. Im folgenden Beispiel wird ein Fehler beim Umwandeln von Datentypen dargestellt. Beim Kompatibilitätsgrad 80 oder niedriger wird die ganzzahlige Konstante `1` in der ersten `SELECT`-Anweisung direkt in den Datentyp der Zielspalte `ReturnedValue` umgewandelt, nämlich `varchar(255)`. Beim Kompatibilitätsgrad 90 wird der Datentyp des `UNION`-Resultsets vor der Umwandlung in die Zielspalte bestimmt. Für die zweite Spalte in der ersten `SELECT`-Anweisung wird der Datentyp int bestimmt. Für die zweite Spalte in der zweiten `SELECT`-Anweisung wird der Datentyp varchar(4) bestimmt. Da der Datentyp int Vorrang vor dem Datentyp varchar(4) hat, wird der Wert `test` in den Datentyp int umgewandelt, wenn die Datentypen des `UNION`-Resultsets bestimmt werden. Dadurch wird ein Datentyp-Konvertierungsfehler erzeugt. `CREATE TABLE #test(ReturnedName varchar(255) NOT NULL, ReturnedValue varchar(255) NULL) INSERT INTO #test SELECT 'col1', 1 UNION ALL SELECT 'test', 'test' DROP TABLE #test`
UPDATETEXT	In SQL Server 2005 wird das Verwenden von Textzeigern in UPDATETEXT-Anweisungen nicht unterstützt, die mithilfe desselben Textzeigers in dieselben BLOB-Daten (Binary Large Objects) lesen und schreiben. Kopieren Sie die BLOB-Daten in eine temporäre Tabelle oder eine Tabellenvariable, und weisen Sie den Wert erneut der ursprünglichen Spalte zu.
WITH-Schlüsselwort beim Verwenden von Tabellenhinweisen	In SQL Server 2005 werden bis auf einige Ausnahmen Tabellenhinweise nur dann in der FROM-Klausel einer Abfrage unterstützt, wenn die Hinweise mithilfe des WITH-Schlüsselwortes angegeben werden. Weitere Informationen finden Sie unter FROM (Transact-SQL) und Tabellenhinweis (Transact-SQL).
ORDER BY in einer Sichtdefinition	In SQL Server 2005 wird die ORDER BY-Klausel in einer Sichtdefinition lediglich zur Bestimmung der Zeilen verwendet, die von der TOP-Klausel zurückgegeben werden. Durch die ORDER BY-Klausel wird keine bestimmte Ergebnisreihenfolge bei der Abfrage der Sicht sichergestellt, es sei denn, in der Abfrage selbst ist ebenfalls ORDER BY angegeben.
UPDATE mit Sperrhinweisen	In SQL Server 2000 werden Sperrhinweise nicht auf Konflikte in einer UPDATE-Anweisung überprüft, wenn die beiden folgenden Bedingungen erfüllt sind: Für die Tabelle in der FROM-Klausel wird ein Alias verwendet. Auf dieselbe Tabelle wird als Ziel der UPDATE-Anweisung ohne Alias verwiesen. SQL Server ignoriert die Sperrhinweise in der FROM-Klausel und gibt bei einem Konflikt keinen Fehler aus. In SQL Server 2005 wird ein Fehler zurückgegeben, wenn für Sperrhinweise unter diesen Bedingungen ein Konflikt besteht.

XML

Feature Beschreibung

Feature	Beschreibung
OPENXML	Aufgrund von Änderungen an MSXML werden in OPENXML keine nicht ganzzahligen Positionsprädikate mehr unterstützt. In SQL Server 2005 ist MSXML 3.0 das zugrunde liegende Modul, das zur Verarbeitung von XPath-Ausdrücken verwendet wird, die in OPENXML-Abfragen verwendet werden. MSXML 3.0 umfasst ein konformeres XPath 1.0-Modul, in dem die Semantik nicht ganzzahliger Werte in Positionsprädikaten geändert wurde. Der folgende Ausdruck gibt als XPath-Ausdruck `a[5.1]` jetzt beispielsweise kein Element statt des fünften `<a>`-Elements zurück. Verwenden Sie den gerundeten Wert direkt, um dies zu korrigieren. Ändern Sie beispielsweise das vorherige Beispiel in `a[5]`.
OPENXML XPath-Ausdrücke	MSXML 3.0 beinhaltet ein strengeres XPath 1.0-Modul, in dem die folgenden Funktionen nicht mehr unterstützt werden: format-number() formatNumber() current() element-available() function-available() system-property() Für format-number() und formatNumber() können Sie Transact-SQL verwenden. Für die anderen nicht unterstützten Funktionen gibt es keine direkte Problemumgehung.
Benutzerdefinierter Typ 'xml'	In SQL Server 2005 ist xml ein reservierter Systemtyp. Benennen Sie den Typ vor oder nach dem Update mithilfe von sp_rename um, und ändern Sie die Anwendung so, dass sie mit dem neuen Typnamen arbeitet.

OPENXML

Aufgrund von Änderungen an MSXML werden in OPENXML keine nicht ganzzahligen Positionsprädikate mehr unterstützt. In SQL Server 2005 ist MSXML 3.0 das zugrunde liegende Modul, das zur Verarbeitung von XPath-Ausdrücken verwendet wird, die in OPENXML-Abfragen verwendet werden. MSXML 3.0 umfasst ein konformeres XPath 1.0-Modul, in dem die Semantik nicht ganzzahliger Werte in Positionsprädikaten geändert wurde.

Der folgende Ausdruck gibt als XPath-Ausdruck a[5.1] jetzt beispielsweise kein Element statt des fünften <a>-Elements zurück. Verwenden Sie den gerundeten Wert direkt, um dies zu korrigieren. Ändern Sie beispielsweise das vorherige Beispiel in a[5].

OPENXML XPath-Ausdrücke

MSXML 3.0 beinhaltet ein strengeres XPath 1.0-Modul, in dem die folgenden Funktionen nicht mehr unterstützt werden:

format-number()
formatNumber()
current()
element-available()
function-available()
system-property()

Für format-number() und formatNumber() können Sie Transact-SQL verwenden. Für die anderen nicht unterstützten Funktionen gibt es keine direkte Problemumgehung.

Benutzerdefinierter Typ 'xml'

In SQL Server 2005 ist xml ein reservierter Systemtyp. Benennen Sie den Typ vor oder nach dem Update mithilfe von sp_rename um, und ändern Sie die Anwendung so, dass sie mit dem neuen Typnamen arbeitet.

Siehe auch

Änderungsverlauf

Version	Verlauf
17. November 2008	Neuer Inhalt: Im Abschnitt "Features" wurde ein Eintrag über die Spaltensortierungsübersintimmung in Tabellenvariablen hinzugefügt.
14. April 2006	Neuer Inhalt: Dem Abschnitt zu Transact-SQL wurde ein Eintrag bezüglich der Verwendung von ORDER BY in einer Sichtdefinition hinzugefügt. Dem Abschnitt zu Transact-SQL wurde ein Eintrag bezüglich der Verwendung von Sperrhinweisen mit UPDATE hinzugefügt.