Neues in SQLXML 4.0 SP1

Anwendungsbereich:yesSQL Server (alle unterstützten Versionen) YesAzure 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 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 Datentypen, die in SQL Server 2005 (9.x) eingeführt wurden

  • Ä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 wurde SQLXML 4.0 mit SQL Server veröffentlicht und war Teil der Standardinstallation aller SQL Server Versionen außer 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 SP1herunter.

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, die als Teil der 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 und Adding Custom Prerequisites.

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). Dies finden Sie an 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.

Sie müssen auch SQL Server Native Client neu verteilen, wenn Sie sie 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, dieselbe Version von SQL Server Native Client Anbieter und SQL Server zu verwenden, da SQL Server Native Client entwickelt wird, um alle neuen Datentypen zu unterstützen, die auf dem Server ausgeliefert werden, z. B. Datum, Uhrzeit, DateTime2 und dateTimeOffset-Datentypen in SQL Server 2008 und unterstützt von SQL Server 2019 (15.x) Native Client.

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 können 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 Programmierung.

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.

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

SQL Server 2005 (9.x) 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 hat die Datentypen "Date", "Time", "DateTime2" und "DateTimeOffset" eingeführt. SQLXML 4.0 SP1 aktiviert diese vier neuen Datentypen als integrierte Skalartypen bei Verwendung mit SQL Server 2019 (15.x) Native Client OLE DB Provider (SQLNCLI11), der in SQL Server 2019 (15.x) ausgeliefert wird.

Ä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 ihre Lösung die erweiterten Datentypfunktionen erfordert, die in SQL Server 2005 (9.x) eingeführt wurden, z. B. den XML-Datentyp oder die benutzerdefinierten Datentypen (UDTs) und den webbasierten Zugriff, eine andere Lösung wie SQLXML verwaltete Klassen oder einen anderen TYP von HTTP-Handlern verwenden, z. B. native XML-Webdienste für SQL Server 2005.

Alternativ können Sie, wenn Sie diese Typerweiterungen nicht benötigen, weiterhin SQLXML 3.0 verwenden, um eine Verbindung mit SQL Server 2005 (9.x) und SQL Server 2008-Installationen herzustellen. Die SQLXML 3.0 ISAPI-Unterstützung funktioniert mit diesen späteren Versionen, unterstützt aber nicht den xml-Datentyp oder die UDT-Typunterstützung, die in SQL Server 2005 (9.x) eingeführt wurde.

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

Für SQLXML 4.0 und SQL Server wird 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 zurückgegeben werden würde, 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.