Neues in SQLXML 4.0 SP1

Gilt für:SQL ServerAzure SQL-Datenbank

Microsoft SQLXML 4.0 SP1 enthält verschiedene Updates und Verbesserungen. Dieses Thema fasst die Updates zusammen und enthält Links zu ausführlicheren Informationen, sofern verfügbar. SQLXML 4.0 SP1 bietet zusätzliche Verbesserungen zur Unterstützung der neuen Datentypen, die in SQL Server 2008 (10.0.x) eingeführt wurden. 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 (9.x)

• Ä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 SQL Server 2008 (10.0.x) wurde SQLXML 4.0 mit SQL Server veröffentlicht und war Teil der Standardinstallation aller SQL Server-Versionen mit Ausnahme von SQL Server Express. Ab SQL Server 2008 (10.0.x) 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 SP1herunter.

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

%PROGRAMFILES%\SQLXML 4.0\

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 als Teil der INSTALLATION von SQL Server 2005 (9.x) oder höher installiert ist.

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 Authoring a Custom Bootstrapper Package for Visual Studio 2005 (Erstellen eines benutzerdefinierten Bootstrapper-Pakets für Visual Studio 2005) und Adding Custom Prerequisites (Hinzufügen benutzerdefinierter Voraussetzungen).

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 finden Sie auf der SQL Server-Installations-CD am folgenden 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.

Sie müssen sql Server Native Client auch erneut verteilen, wenn Sie ihn als Datenanbieter mit Ihrer Anwendung verwenden. Weitere Informationen finden Sie unter Installing SQL Server Native Client.

Unterstützung für SQL Server Native Client

SQLXML 4.0 unterstützt sowohl die SQLOLEDB- als auch sql Server Native Client-Anbieter. Es wird empfohlen, die gleiche Version von SQL Server Native Client provider und SQL Server zu verwenden, da SQL Server Native Client entwickelt wird, um alle neuen Datentypen zu unterstützen, die auf dem Server enthalten sind, z . B. Datum, Uhrzeit, DateTime2 und dateTimeOffset-Datentypen in SQL Server 2008 (10.0.x) und von SQL Server Native Client unterstützt werden.

SQL Server Native Client ist eine Datenzugriffstechnologie, die in SQL Server 2005 (9.x) 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 verbessern, die in SQL Server eingeführte Features nutzen müssen, die von SQLOLEDB und SQLODBC in MDAC und Microsoft Windows nicht unterstützt werden. Beispielsweise ist SQL Server Native Client für clientseitige SQLXML-Features 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 sql Server Native Client Programming.

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

SQL Server 2005 (9.x) hat den 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.

• Standardzuordnung von XSD-Elementen und Attributen zu Tabellen und Spalten

• Einfügen von Daten mithilfe von XML-Updatediagrammen

• Beispiele für das Massenladen von XML-Dokumenten

SQL Server 2008 (10.0.x) hat die Datentypen Date, Time, DateTime2 und DateTimeOffset eingeführt. SQLXML 4.0 SP1 aktiviert diese vier neuen Datentypen als integrierte skalare Typen bei Verwendung mit SQL Server Native Client OLE DB Provider (SQLNCLI11), die in SQL Server 2012 (11.x) enthalten sind.

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

• Für SQLXML 4.0 wird das SchemaGen-Überlauffeld mithilfe des XML-Datentyps 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 Verweis auf Xblkld4.dll neu 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.

Ä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 systemeigene Fehlerinformationen zurück, die von OLE DB und SQL Server anstelle eines sqlXML-Fehlers auf hoher Ebene bereitgestellt werden (wie in früheren Versionen von SQLXML). 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. {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    . This is a line feed and CR   
   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   
   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 aus SQLXML 4.0 entfernt wurde, müssen Sie, wenn für Ihre Lösung die erweiterten Datentypisierungsfeatures erforderlich sind, die in SQL Server 2005 (9.x) eingeführt wurden, z. B. den XML-Datentyp oder benutzerdefinierte Datentypen (UDTs) und den webbasierten Zugriff, eine andere Lösung wie sqlXML managed classes oder einen anderen Typ von HTTP-Handler verwenden. z. B. native XML-Webdienste für SQL Server 2005.

Wenn Sie diese Typerweiterungen nicht benötigen, können Sie auch weiterhin SQLXML 3.0 verwenden, um eine Verbindung mit SQL Server 2005 (9.x) und SQL Server 2008 (10.0.x)-Installationen herzustellen. Die SQLXML 3.0 ISAPI-Unterstützung funktioniert für diese späteren Versionen, unterstützt oder erkennt jedoch nicht den xml-Datentyp oder die IN SQL Server 2005 (9.x) eingeführte UNTERSTÜTZUNG für XML-Datentypen oder UDT-Typ.

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 Massenladevorgang ausführt, XML-Massenladedateiberechtigungen gewährt. 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 unterschiedliche Werte in den Metadaten für eine Basistabelle zurück, als wenn die FOR XML-Abfrage unter SQL Server 2000 (8.x) ausgeführt wurde. 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 der SQL Server Native Client (SQLNCLI11) als Anbieter angegeben wird, werden die Daten als XML zurückgegeben.