Partager via

Nouveautés de SQLXML 4.0 SP1

  • Article

S’applique à : SQL Server Azure 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 présentés 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 était fourni 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. À partir 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 de SQLXML 4.0 SP1.

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

%PROGRAMFILES%\SQLXML 4.0\

Remarque

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 version 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). Ceux-ci se trouvent sur le programme 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 devrez également redistribuer SQL Server Native Client si vous l'utilisez comme 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 par 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.

Remarque

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 qui a été 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 des applications ou améliorer des 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 que des fonctionnalités SQLXML côté client, telles que FOR XML, puissent utiliser le type de données xml. Pour plus d'informations, voir Formatage XML côté client (SQLXML 4.0), Utilisation d'ADO pour exécuter des requêtes SQLXML 4.0, et Programmation du client natif de SQL Server.

Remarque

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, voir le support des types de données xml dans SQLXML 4.0.

Pour obtenir des exemples illustrant l'utilisation du type de données xml dans SQLXML lors du mappage de vues XML, du chargement en masse XML ou de l'exécution de codes de mise à jour XML, consultez les 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 activera ces quatre nouveaux types de données sous la forme de types scalaires intégrés lors d'une utilisation avec le fournisseur OLE DB SQL Server Native Client (SQLNCLI11), fourni avec SQL Server 2012 (11.x).

Important

SQL Server Native Client (SNAC) n’est pas fourni avec :

  • 2022 - SQL Server 16 (16.x) et versions ultérieures
  • SQL Server Management Studio 19 et versions ultérieures

SQL Server Native Client (SQLNCLI ou SQLNCLI11) et le fournisseur Microsoft OLE DB pour SQL Server (SQLOLEDB) hérité ne sont pas recommandés pour le développement de nouvelles applications.

Pour les nouveaux projets, utilisez l'un des pilotes suivants :

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 de débordement SchemaGen est créé en utilisant le type de données xml. Pour plus d'informations, voir SQL Server XML Bulk Load Object Model.

  • Si vous avez précédemment créé des applications Microsoft Visual Basic et que vous souhaitez utiliser SQLXML 4.0, vous devez recompiler l'application avec une 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")

    Remarque

    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 native fournies par OLE DB et SQL Server au lieu d'une erreur SQLXML de niveau supérieur (comme cela é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 du GUID soit renvoyée avec les accolades (par exemple, {quelque GUID}), la valeur de cette clé de registre doit être fixée à 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, voir 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

Le support ISAPI ayant été supprimé de SQLXML 4.0, si votre solution nécessite les fonctionnalités de typage 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 basé sur le Web, vous devrez utiliser une autre solution, telle que les classes gérées SQLXML ou un autre type de gestionnaire HTTP, tel que Native XML Web Services for SQL Server 2005.

Si vous n'avez pas besoin de ces extensions de type, vous pouvez continuer à utiliser SQLXML 3.0 pour vous connecter aux installations SQL Server 2005 (9.x) et SQL Server 2008 (10.0.x). Le support ISAPI SQLXML 3.0 fonctionnera avec ces versions ultérieures mais ne supporte pas ou ne reconnaît pas le support du type de données xml ou du type UDT introduit 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 permissions du fichier XML Bulk Load sont accordées à l'utilisateur qui exécute l'opération de chargement en masse. 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 de changements dans le moteur d'exécution, SQL Server peut renvoyer des valeurs différentes dans les métadonnées d'une table de base que celles qui seraient renvoyées si la requête FOR XML était 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 dans les résultats reviendront sous la forme d'une chaîne entièrement décomposée. Dans SQLXML 4.0, si SQL Server Native Client (SQLNCLI11) est spécifié en tant que fournisseur, les données seront retournées sous forme de données XML.