Nouveautés de SQLXML 4.0 SP1

  • Article

S’applique à :SQL ServerAzure SQL Database

Microsoft SQLXML 4.0 SP1 inclut différentes mises à jour et améliorations. Cette rubrique résume les mises à jour et fournit, le cas échéant, des liens vers des pages contenant des informations plus détaillées. SQLXML 4.0 SP1 fournit des améliorations supplémentaires pour prendre en charge les nouveaux types de données introduits dans SQL Server 2008 (10.0.x). Cette rubrique traite des sujets suivants :

  • Installation de SQLXML 4.0 SP1

  • Problèmes liés à l'installation côte à côte

  • SQLXML 4.0 et MSXML

  • Redistribution de SQLXML 4.0

  • Prise en charge de SQL Server Native Client

  • Prise en charge des types de données introduits dans SQL Server 2005 (9.x)

  • Modifications apportées au chargement en masse XML pour SQLXML 4.0

  • Modifications apportées aux clés de Registre pour SQLXML 4.0

  • Problèmes de migration

Installation de SQLXML 4.0 SP1

Avant SQL Server 2008 (10.0.x), SQLXML 4.0 a été publié avec SQL Server et faisait partie de l’installation par défaut de toutes les versions de SQL Server, à l’exception de SQL Server Express. À compter de SQL Server 2008 (10.0.x), la dernière version de SQLXML (SQLXML 4.0 SP1) n’est plus incluse dans SQL Server. Pour installer SQLXML 4.0 SP1, téléchargez-le à partir de l’emplacement d’installation pour SQLXML 4.0 SP1.

Les fichiers SQLXML 4.0 SP1 sont installés à l'emplacement suivant :

%PROGRAMFILES%\SQLXML 4.0\

Note

Tous les paramètres du Registre appropriés pour SQLXML 4.0 sont définis dans le cadre de la procédure d'installation.

Pour permettre l'exécution des applications SQLXML 32 bits sous WOW64 (Windows on Windows64) sur les systèmes d'exploitation Windows 64 bits, exécutez le package SQLXML 4.0 SP1 64 bits, nommé sqlxml4.msi, qui se trouve sur le Centre de téléchargement.

Désinstallation de SQLXML 4.0 SP1

Il existe des clés de Registre partagées entre SQLXML 3.0 SP3, SQLXML 4.0 et SQLXML 4.0 SP1. Si les versions ultérieures de SQLXML sont désinstallées sur le même ordinateur qui contient SQLXML 3.0 SP3, il est possible que vous deviez réinstaller SQLXML 3.0 SP3.

Problèmes liés à l'installation côte à côte

La procédure d'installation de SQLXML 4.0 ne supprime pas les fichiers installés par les versions antérieures de SQLXML. Par conséquent, les DLL de différentes installations de SQLXML avec des versions distinctes peuvent figurer sur votre ordinateur. Vous pouvez exécuter les installations côte à côte. SQLXML 4.0 inclut des PROGID dépendants et indépendants de la version. Toutes les applications de production doivent utiliser des PROGID dépendants de la version.

SQLXML 4.0 SP1 et MSXML

SQLXML 4.0 n'installe pas MSXML. SQLXML 4.0 utilise MSXML 6.0, qui est installé dans le cadre de l’installation de SQL Server 2005 (9.x) ou ultérieure.

Redistribution de SQLXML 4.0 SP1

Vous pouvez distribuer SQLXML 4.0 SP1 en utilisant le package du programme d'installation redistribuable. Une façon d'installer plusieurs packages dans ce qui paraît à l'utilisateur être une installation unique consiste à utiliser la technologie des programmes de chaînage et d'amorçage. Pour plus d’informations, consultez Création d’un package de programme d’amorçage personnalisé pour Visual Studio 2005 et Ajout de composants requis personnalisés.

Si votre application vise une plateforme autre que celle sur laquelle elle a été développée, vous pouvez télécharger les versions de sqlncli.msi pour x64, Itanium et x86 à partir du Centre de téléchargement Microsoft.

Il existe également des programmes d'installation de redistribution séparés pour MSXML 6.0 (msxml6.msi). Vous trouverez ces informations sur le CD d’installation de SQL Server à l’emplacement suivant :

%CD%\Setup\

Ces fichiers d'installation peuvent être utilisés pour installer MSXML 6.0 directement à partir du CD. Ils peuvent également être utilisés pour redistribuer librement MSXML 6.0 et SQLXML 4.0 SP1 avec vos propres applications personnalisées.

Vous devez également redistribuer SQL Server Native Client si vous l’utilisez en tant que fournisseur de données avec votre application. Pour plus d’informations, consultez Installation de SQL Server Native Client.

Prise en charge de SQL Server Native Client

SQLXML 4.0 prend en charge les fournisseurs SQLOLEDB et SQL Server Native Client. Il est recommandé d’utiliser la même version du fournisseur SQL Server Native Client et de SQL Server, car SQL Server Native Client est développé pour prendre en charge tous les nouveaux types de données fournis dans le serveur, tels que les types de données Date, Heure, DateTime2 et DateTimeOffset dans SQL Server 2008 (10.0.x) et pris en charge par SQL Server Native Client.

Note

SQL Server Native Client a été supprimé dans SQL Server 2022 (16.x).

SQL Server Native Client est une technologie d’accès aux données introduite dans SQL Server 2005 (9.x). Elle associe le fournisseur SQLOLEDB et le pilote SQLODBC dans une même bibliothèque de liens dynamiques (DLL), tout en proposant également de nouvelles fonctionnalités distinctes des composants MDAC (Microsoft Data Access Components).

SQL Server Native Client peut être utilisé pour créer de nouvelles applications ou améliorer les applications existantes qui doivent tirer parti des fonctionnalités introduites dans SQL Server qui ne sont pas prises en charge par SQLOLEDB et SQLODBC dans MDAC et Microsoft Windows. Par exemple, SQL Server Native Client est requis pour les fonctionnalités SQLXML côté client, telles que FOR XML, pour utiliser le type de données xml . Pour plus d’informations, consultez Mise en forme XML côté client (SQLXML 4.0), Utilisation d’ADO pour exécuter des requêtes SQLXML 4.0 et programmation SQL Server Native Client.

Note

SQLXML 4.0 n'assure pas une compatibilité descendante complète avec SQLXML 3.0. En raison de quelques résolutions de bogue et d'autres modifications fonctionnelles, en particulier la suppression de la prise en charge de l'interface ISAPI SQLXML, vous ne pouvez pas utiliser de répertoires virtuels IIS avec SQLXML 4.0. Bien que la plupart des applications s'exécutent avec des modifications mineures, vous devez les tester avant de les mettre en production avec SQLXML 4.0.

Prise en charge des types de données introduits dans SQL Server 2005 et SQL Server 2008

SQL Server 2005 (9.x) a introduit le type de données xml et SQLXML 4.0 prend en charge le type de données xml . Pour plus d’informations, consultez la prise en charge des types de données xml dans SQLXML 4.0.

Pour obtenir des exemples d’utilisation du type de données XML dans SQLXML lors du mappage des vues XML, du chargement en bloc ou de l’exécution de codes de mise à jour XML, reportez-vous aux exemples fournis dans les rubriques suivantes.

SQL Server 2008 (10.0.x) a introduit les types de données Date, Heure, DateTime2 et DateTimeOffset . SQLXML 4.0 SP1 active ces quatre nouveaux types de données en tant que types scalaires intégrés lorsqu’ils sont utilisés avec le fournisseur OLE DB SQL Server Native Client (SQLNCLI11), fourni dans SQL Server 2012 (11.x).

Important

SQL Server Native Client (souvent abrégé en SNAC) a été supprimé dans SQL Server 2022 (16.x) et SQL Server Management Studio 19 (SSMS). SQL Server Native Client (SQLNCLI ou SQLNCLI11) et le fournisseur Microsoft OLE DB pour SQL Server (SQLOLEDB) hérité ne sont pas recommandés dans les nouveaux développements. Utilisez à la place le nouveau Microsoft OLE DB Driver (MSOLEDBSQL) pour SQL Server ou le Microsoft ODBC Driver for SQL Server le plus récent. Pour SQLNCLI qui est fourni en tant que composant du moteur de base de données SQL Server (versions 2012 à 2019), consultez cette exception du cycle de vie du support.

Modifications apportées au chargement en masse XML pour SQLXML 4.0 SP1

  • Pour SQLXML 4.0, le champ schemaGen overflow est créé à l’aide du type de données xml . Pour plus d’informations, consultez SQL Server XML Bulk Load Object Model.

  • Si vous avez déjà créé des applications Microsoft Visual Basic et que vous souhaitez utiliser SQLXML 4.0, vous devez recompiler l’application avec référence à Xblkld4.dll.

  • Pour les applications Visual Basic Scripting Edition, vous devez inscrire la DLL que vous souhaitez utiliser. Dans l'exemple suivant, si vous spécifiez des PROGID indépendants de la version, l'application dépend de la dernière DLL inscrite :

    set objBulkLoad = CreateObject("SQLXMLBulkLoad.SQLXMLBulkLoad")

    Note

    Le PROGID dépendant de la version est SQLXMLBulkLoad.SQLXMLBulkLoad.4.0.

Modifications apportées aux clés de Registre pour SQLXML 4.0

Les clés de Registre ont été modifiées par rapport aux versions précédentes. Dans SQLXML 4.0, elles sont les suivantes :

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

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

Vous devez modifier les paramètres si vous souhaitez que ces clés soient appliquées pour SQLXML 4.0.

De plus, SQLXML 4.0 introduit les clés de Registre suivantes :

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

    Par défaut, SQLXML 4.0 retourne des informations d’erreur natives fournies par OLE DB et SQL Server au lieu d’une erreur SQLXML de haut niveau (comme c’était le cas dans les versions antérieures de SQLXML). Si ce comportement ne vous convient pas, attribuez la valeur 0 à cette clé de Registre de type DWORD (la valeur par défaut est 1).

  • HKEY_LOCAL_MACHINE\Software\Microsoft\MSSQLServer\Client\SQLXML4\FORXML_GenerateGUIDBraces

    Par défaut, SQLXML retourne des valeurs GUID SQL Server sans accolades de délimitation. Si vous souhaitez que la valeur GUID retournée avec les accolades (par exemple, {un GUID}), la valeur de cette clé de Registre doit être définie sur 1 (la valeur par défaut est 0).

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

    Par défaut, lorsque l'analyseur XML charge les données, les espaces blancs sont normalisés selon les règles du langage XML 1.0. Cela entraîne la perte de quelques espaces blancs dans vos données. Par conséquent, la représentation textuelle de vos données peut ne pas être la même après l'analyse, bien que les données soient les mêmes sur le plan sémantique.

    Cette clé est introduite pour que vous puissiez conserver les espaces blancs dans les données si vous le souhaitez. Si vous ajoutez cette clé de Registre et que vous lui attribuez la valeur 0, les espaces blancs (saut de ligne, retour chariot et tabulation) dans le code XML sont retournés encodés en cas de valeurs d'attribut. En cas de valeurs d'élément, seul le retour chariot est retourné encodé.

    Par exemple :

    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>

Problèmes de migration

Les problèmes suivants peuvent affecter la migration de vos applications SQLXML héritées vers SQLXML 4.0.

Requêtes ADO et SQLXML 4.0

Dans les versions antérieures de SQLXML, l'exécution de requêtes basées sur une URL à l'aide de répertoires virtuels IIS et du filtre ISAPI SQLXML était prise en charge. Pour les applications qui utilisent SQLXML 4.0, cette prise en charge n'est plus offerte.

Au lieu de cela, les requêtes, modèles et codes de mise à jour SQLXML peuvent être exécutées à l'aide des extensions SQLXML aux objets ADO (ActiveX Data Objects) qui ont été introduites pour la première fois dans Microsoft Data Access Components (MDAC) 2.6 et versions ultérieures.

Pour plus d’informations, consultez Utilisation d’ADO pour exécuter des requêtes SQLXML 4.0.

Prise en charge de l'interface ISAPI SQLXML 3.0 et des types de données introduits dans SQL Server 2005

Étant donné que la prise en charge d’ISAPI a été supprimée de SQLXML 4.0, si votre solution nécessite les fonctionnalités de saisie de données améliorées introduites dans SQL Server 2005 (9.x), telles que le type de données xml ou les types de données définis par l’utilisateur (UDT) et l’accès web, vous devez utiliser une autre solution telle que des classes managées SQLXML ou un autre type de gestionnaire HTTP, tels que les services web XML natifs pour SQL Server 2005.

Sinon, si vous n’avez pas besoin de ces extensions de type, vous pouvez continuer à utiliser SQLXML 3.0 pour vous connecter à SQL Server 2005 (9.x) et aux installations SQL Server 2008 (10.0.x). La prise en charge de l’ISAPI SQLXML 3.0 fonctionne sur ces versions ultérieures, mais ne prend pas en charge ni ne reconnaît pas le type de données xml ou la prise en charge de type UDT introduite dans SQL Server 2005 (9.x).

Modifications apportées à la sécurité du chargement en masse XML pour les fichiers temporaires

Pour SQLXML 4.0 et SQL Server, les autorisations de fichier de chargement en masse XML sont accordées à l’utilisateur exécutant l’opération de chargement en bloc. Les autorisations en lecture et en écriture sont héritées du système de fichiers. Dans les versions précédentes de SQLXML et de SQL Server, le chargement en masse XML sous SQLXML créait des fichiers temporaires qui n'étaient pas sécurisés et qui pouvaient être lus par n'importe qui.

Problèmes de migration pour FOR XML côté client

En raison des modifications apportées au moteur d’exécution, SQL Server peut retourner des valeurs différentes dans les métadonnées d’une table de base que si la requête FOR XML a été exécutée sous SQL Server 2000 (8.x). Si cela se produit, la mise en forme côté client des résultats de la requête FOR XML aura une sortie différente selon la version sur laquelle la requête est exécutée.

Si une requête FOR XML est exécutée côté client à l’aide de SQLXML 3.0 sur une colonne de type de données xml , les données contenues dans les résultats sont renvoyées sous forme de chaîne entièrement entitisée. Dans SQLXML 4.0, si SQL Server Native Client (SQLNCLI11) est spécifié en tant que fournisseur, les données sont retournées au format XML.