Neues in SQLXML 4.0 SP1

Artikel
08/06/2013

Microsoft SQLXML 4.0 SP1 umfasst verschiedene Updates und Erweiterungen. Dieses Thema fasst die Updates zusammen und enthält Links zu ausführlicheren Informationen, sofern verfügbar. SQLXML 4.0 SP1 bietet zusätzliche Erweiterungen zur Unterstützung der neuen Datentypen in SQL Server 2008. Dieses Thema enthält die folgenden Themen:

Installieren von SQLXML 4.0 SP1
Probleme bei gleichzeitiger Installation
SQLXML 4.0 und MSXML
Neuverteilen von SQLXML 4.0
Unterstützung für SQL Server Native Client
Unterstützung für in SQL Server 2005 eingeführte Datentypen
Änderungen für XML-Massenladen für SQLXML 4.0
Änderungen des Registrierungsschlüssels für SQLXML 4.0
Migrationsprobleme

Installieren von SQLXML 4.0 SP1

Vor der Veröffentlichung von SQL Server 2008 wurde SQLXML 4.0 mit SQL Server veröffentlicht und war Bestandteil der Standardinstallation aller SQL Server-Versionen mit Ausnahme von SQL Server Express. Ab SQL Server 2008 ist die neueste Version von SQLXML (SQLXML 4.0 SP1) nicht mehr in SQL Server enthalten. Zum Installieren von SQLXML 4.0 SP1 laden Sie dieses von Installationspfad für SQLXML 4.0 SP1 herunter.

Die SQLXML 4.0 SP1-Dateien werden an folgendem Speicherort installiert:

%PROGRAMFILES%\SQLXML 4.0\

Hinweis
Alle entsprechenden Registrierungseinstellungen für SQLXML 4.0 werden im Rahmen des Installationsprozesses festgelegt.

Um die Ausführung von 32-Bit-SQLXML-Anwendungen unter Windows on Windows (WOW64) auf 64-Bit-Windows-Betriebssystemen zu ermöglichen, führen Sie das 64-Bit-SQLXML 4.0 SP1-Paket mit dem Namen sqlxml4.msi aus, das Sie im Download Center finden.

Deinstallieren von SQLXML 4.0 SP1

Bestimmte Registrierungsschlüssel werden von SQLXML 3.0 SP3, SQLXML 4.0 und SQLXML 4.0 SP1 gemeinsam verwendet. Wenn spätere SQLXML-Versionen auf einem Computer deinstalliert werden, auf dem auch SQLXML 3.0 SP3 installiert ist, müssen Sie SQLXML 3.0 SP3 möglicherweise neu installieren.

Probleme bei gleichzeitiger Installation

Durch die Installation von SQLXML 4.0 werden keine Dateien, die von früheren Versionen von SQLXML installiert wurden, entfernt. Daher können auf dem Computer DLLs für verschiedene versionsabhängige Installationen von SQLXML vorhanden sein. Sie können die Installationen parallel ausführen. SQLXML 4.0 umfasst sowohl versionsunabhängige als auch versionsabhängige Programm-IDs. Es wird empfohlen, für alle Produktionsanwendungen versionsabhängige Programm-IDs zu verwenden.

SQLXML 4.0 SP1 und MSXML

MSXML wird von SQLXML 4.0 nicht installiert. SQLXML 4.0 verwendet MSXML 6.0, das im Rahmen der Installation von SQL Server 2005 oder höher installiert wird.

Verteilen von SQLXML 4.0 SP1

Sie können SQLXML 4.0 SP1 mit dem weitervertreibbaren Installer-Paket weitergeben. Eine Möglichkeit, mehrere Pakete in mehreren Installationen, die für den Benutzer wie eine Installation aussehen, zu installieren, besteht in der Verwendung der Chainer- und Bootstrappertechnologie. Weitere Informationen finden Sie unter "Erstellen eines benutzerdefinierten Bootstrapper-Packets für Visual Studio 2005" und "Hinzufügen von benutzerdefinierten erforderlichen Komponenten".

Wenn Ihre Anwendung für eine andere Plattform als für diejenige vorgesehen ist, auf der sie entwickelt wurde, können Sie Versionen von sqlncli.msi für x64, Itanium und x86 vom Microsoft Download Center herunterladen.

Es gibt auch separate weitervertreibbare Installationsprogramme für MSXML 6.0 (msxml6.msi). Diese befinden sich auf der SQL Server Installations-CD an folgendem Speicherort:

%CD%\Setup\

Mit diesen Installationsdateien kann MSXML 6.0 direkt von der CD installiert werden. Mit den Dateien können MSXML 6.0 zusammen mit SQLXML 4.0 SP1 auch mit eigenen benutzerdefinierten Anwendungen kostenlos verteilt werden.

SQL Server Native Client muss ebenfalls neu verteilt werden, wenn Sie es mit Ihrer Anwendung als Datenanbieter verwenden. Weitere Informationen finden Sie unter Installieren von SQL Server Native Client.

Unterstützung für SQL Server Native Client

SQLXML 4.0 unterstützt den SQLOLEDB- und den SQL Server Native Client-Anbieter. Es wird empfohlen, die gleiche Version des SQL Server Native Client-Anbieters und von SQL Server zu verwenden, da SQL Server Native Client für die Unterstützung der vom Server unterstützten neuen Datentypen entwickelt wurde, z. B. der Datentypen Date, Time, DateTime2 und dateTimeOffset in SQL Server 2008, die von SQL Server 2012 Native Client unterstützt werden.

SQL Server Native Client ist eine neue Datenzugriffstechnologie, die in SQL Server 2005 eingeführt wurde. Dabei werden die SQLOLEDB-Anbieter und der SQLODBC-Treiber in einer systemeigenen DLL (Dynamic Link Library) zusammengeführt. Außerdem wird eine neue eigenständige Funktionalität bereitgestellt, die sich von Microsoft Data Access Components (MDAC) unterscheidet.

SQL Server Native Client kann verwendet werden, um neue Anwendungen zu erstellen oder vorhandene Anwendungen zu erweitern, die in SQL Server eingeführte Funktionen nutzen, die von SQLOLEDB und SQLODBC in MDAC und Microsoft Windows nicht unterstützt werden. SQL Server Native Client ist beispielsweise für clientseitige SQLXML-Funktionen wie FOR XML erforderlich, um den xml-Datentyp zu verwenden. Weitere Informationen finden Sie unter Clientseitige XML-Formatierung (SQLXML 4.0), Verwenden von ADO zum Ausführen von SQLXML 4.0-Abfragen und Programmierung für SQL Server Native Client.

Hinweis
SQLXML 4.0 ist mit SQLXML 3.0 nicht vollkommen abwärts kompatibel. Virtuelle IIS-Verzeichnisse können aufgrund einiger Fehlerbehebungen und anderer funktioneller Änderungen, insbesondere der Einstellung der SQLXML ISAPI-Unterstützung, nicht mit SQLXML 4.0 verwendet werden. Obwohl die meisten Anwendungen mit geringfügigen Änderungen ausgeführt werden können, müssen sie vor der Inbetriebnahme mit SQLXML 4.0 getestet werden.

SQLXML 4.0 ist mit SQLXML 3.0 nicht vollkommen abwärts kompatibel. Virtuelle IIS-Verzeichnisse können aufgrund einiger Fehlerbehebungen und anderer funktioneller Änderungen, insbesondere der Einstellung der SQLXML ISAPI-Unterstützung, nicht mit SQLXML 4.0 verwendet werden. Obwohl die meisten Anwendungen mit geringfügigen Änderungen ausgeführt werden können, müssen sie vor der Inbetriebnahme mit SQLXML 4.0 getestet werden.

Unterstützung für in SQL Server 2005 und SQL Server 2008 neue Datentypen

In SQL Server 2005 wurde der xml-Datentyp eingeführt, und SQLXML 4.0 unterstützt den xml-Datentyp. Weitere Informationen finden Sie unter XML-Datentypunterstützung für SQLXML 4.0.

Beispiele, wie der xml-Datentyp in SQLXML zum Zuordnen von XML-Sichten, Massenladen von XML oder Ausführen von XML-Updategrams verwendet wird, finden Sie in den folgenden Themen.

SQL Server 2008 unterstützt erstmals die Datentypen Date, Time, DateTime2 und DateTimeOffset. SQLXML 4.0 SP1 aktiviert diese vier neuen Datentypen als integrierte skalare Typen, wenn diese mit dem mit SQL Server 2012 gelieferten SQL Server 2012 Native Client-OLE DB-Anbieter (SQLNCLI11) verwendet werden.

Änderungen für XML-Massenladen für SQLXML 4.0 SP1

Für SQLXML 4.0 wird das SchemaGen-Überlauffeld mit dem xml-Datentyp erstellt. Weitere Informationen finden Sie unter SQL Server XML Bulk Load-Objektmodell.
Wenn Sie zuvor Microsoft Visual Basic-Anwendungen erstellt haben und SQLXML 4.0 verwenden möchten, müssen Sie die Anwendung mit einem Verweis auf Xblkld4.dll erneut kompilieren.
Für VBScript-Anwendungen (Visual Basic Scripting Edition) müssen Sie die DLL registrieren, die Sie verwenden möchten. Wenn Sie im folgenden Beispiel versionsunabhängige Programm-IDs angeben, hängt die Anwendung von der zuletzt registrierten DLL ab:
```
set objBulkLoad = CreateObject("SQLXMLBulkLoad.SQLXMLBulkLoad") 
```
Hinweis

Die versionsabhängige Programm-ID ist SQLXMLBulkLoad.SQLXMLBulkLoad.4.0.

Hinweis
Die versionsabhängige Programm-ID ist SQLXMLBulkLoad.SQLXMLBulkLoad.4.0.

Änderungen des Registrierungsschlüssels für SQLXML 4.0

In SQLXML 4.0 wurden die Registrierungsschlüssel aus den früheren Versionen wie folgt geändert:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\SQLXML4\TemplateCacheSize

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\SQLXML4\SchemaCacheSize

Sie müssen die Einstellungen ändern, wenn diese Schlüssel für SQLXML 4.0 gültig sein sollen.

Außerdem führt SQLXML 4.0 die folgenden Registrierungsschlüssel ein:

HKEY_LOCAL_MACHINE\Software\Microsoft\MSSQLServer\Client\SQLXML4\ReportErrorsWithSQLInfo

Standardmäßig gibt SQLXML 4.0 von SQL Server bereitgestellte systemeigene Fehlerinformationen statt eines SQLXML-Fehlers auf hoher Ebene (wie in früheren Versionen von SQLXML) zurück. Ist dieses Verhalten nicht erwünscht, muss der Wert dieses Registrierungsschlüssels des Typs DWORD auf 0 (NULL) gesetzt werden (der Standardwert ist 1).
HKEY_LOCAL_MACHINE\Software\Microsoft\MSSQLServer\Client\SQLXML4\FORXML_GenerateGUIDBraces

Standardmäßig gibt SQLXML SQL Server GUID-Werte ohne geschweifte Klammern zurück. Wenn der GUID-Wert in geschweiften Klammern zurückgegeben werden soll (z. B. {some GUID}) muss der Wert für diesen Registrierungsschlüssel auf 1 gesetzt werden (der Standardwert ist 0).

HKEY_LOCAL_MACHINE\Software\Microsoft\MSSQLServer\Client\SQLXML4\SQL2000CompatMode

Wenn der XML-Parser die Daten lädt, werden Leerzeichen standardmäßig den XML 1.0-Regeln entsprechend normalisiert. Dadurch gehen einige Leerzeichen in Ihren Daten verloren. Daher ist die Textdarstellung Ihrer Daten nach der Analyse möglicherweise nicht unverändert, wobei die Daten semantisch jedoch identisch sind.

Dieser Schlüssel wurde eingeführt, sodass Sie die Leerzeichen in den Daten bei Bedarf beibehalten können. Wenn Sie diesen Registrierungsschlüssel hinzufügen und seinen Wert auf 0 (NULL) setzen, werden Leerzeichen (LF, CR und TAB) in XML bei Attributwerten codiert zurückgegeben. Bei Elementwerten wird nur CR codiert zurückgegeben.

Beispiel:

CREATE TABLE T( Col1 int, Col2 nvarchar(100));
GO
-- Insert data with tab, line feed and carriage return).
INSERT INTO T VALUES (1, 'This is a tab    . This is a line feed and CR 
 more text');
GO
-- Test this query (without the registry key).
SELECT * FROM T 
FOR XML AUTO;
-- This is the result (no encoding of special characters).
<?xml version="1.0" encoding="utf-8" ?>
<r>
  <T Col1="1" 
     Col2="This is a tab    . This is a line feed and CR 
 more text"/>
</r>
-- Now add registry key with value 0 and execute the query again.
-- Note the encoding for carriage return, line-feed and tab in the attribute value.
<?xml version="1.0" encoding="utf-8" ?>
<r>
  <T Col1="1" 
     Col2="This is a tab &#x09;. This is a line feed and CR &#x0D;&#x0A; more text"/>
</r>

-- Update the query and specify ELEMENTS directive
SELECT * FROM T
FOR XML AUTO, ELEMENTS
-- Only the carriage return is returned encoded.
<?xml version="1.0" encoding="utf-8" ?>
<r>
   <T>
      <Col1>1</Col1>
      <Col2>This is a tab    . This is a line feed and CR &#x0D;
 more text</Col2>
   </T>
</r>

Migrationsprobleme

Die folgenden Probleme können sich negativ auf die Migration der älteren SQLXML-Anwendungen auf SQLXML 4.0 auswirken.

ADO- und SQLXML 4.0-Abfragen

In früheren Versionen von SQLXML wurde die URL-basierte Abfrageausführung mit virtuellen IIS-Verzeichnissen und dem SQLXML ISAPI-Filter unterstützt. Für Anwendungen, die SQLXML 4.0 verwenden, ist diese Unterstützung nicht mehr verfügbar.

Stattdessen können SQLXML-Abfragen, -Vorlagen und -Updategrams mit den SQLXML-Erweiterungen für ActiveX Data Objects (ADO) ausgeführt werden, die in Microsoft Data Access Components (MDAC) 2.6 eingeführt wurden.

Weitere Informationen finden Sie unter Verwenden von ADO zum Ausführen von SQLXML 4.0-Abfragen.

Unterstützung für SQLXML 3.0 ISAPI und in SQL Server eingeführte Datentypen

Da die ISAPI-Unterstützung in SQLXML 4.0 eingestellt wurde, müssen Sie, wenn Ihre Lösung die in SQL Server 2005 eingeführten verbesserten Datentypfunktionen wie den xml-Datentyp oder benutzerdefinierte Datentypen (UDTs) sowie webbasierten Zugriff erfordert, eine andere Lösung wie verwaltete SQLXML-Klassen oder einen anderen HTTP-Handlertyp wie Systemeigene XML-Webdienste für SQL Server 2005 verwenden.

Wenn diese Typerweiterungen nicht erforderlich sind, können Sie alternativ SQLXML 3.0 weiter verwenden, um eine Verbindung mit SQL Server 2005- und SQL Server 2008-Installationen herzustellen. Die SQLXML 3.0 ISAPI-Unterstützung funktioniert mit diesen höheren Versionen, unterstützt oder erkennt jedoch den xml-Datentyp oder die in SQL Server 2005 eingeführte UDT-Typunterstützung nicht.

Sicherheitsänderungen für das XML-Massenladen für temporäre Dateien

Für SQLXML 4.0 und SQL Server werden dem Benutzer, der den Massenladenvorgang ausführt, Dateiberechtigungen für das XML-Massenladen erteilt. Lese- und Schreibberechtigungen werden vom Dateisystem geerbt. In früheren Versionen von SQLXML und SQL Server wurden durch das XML-Massenladen unter SQLXML temporäre Dateien erstellt, die nicht sicher waren und von allen Benutzern gelesen werden konnten.

Migrationsprobleme für clientseitiges FOR XML

Aufgrund von Änderungen im Ausführungsmodul gibt SQL Server möglicherweise andere Werte in den Metadaten für eine Basistabelle zurück als bei einer Ausführung der FOR XML-Abfrage unter SQL Server 2000. In diesen Fällen hat die clientseitige Formatierung der FOR XML-Abfrageergebnisse abhängig von der Version, mit der die Abfrage ausgeführt wird, eine andere Ausgabe.

Wenn eine FOR XML-Abfrage clientseitig mit SQLXML 3.0 über eine xml-Datentypspalte ausgeführt wird, werden die Daten in den Ergebnissen als vollständige in Entitäten geänderte Zeichenfolge zurückgegeben. Wenn in SQLXML 4.0 als Anbieter SQL Server Native Client (SQLNCLI11) angegeben ist, werden die Daten als XML zurückgegeben.

Freigeben über