Partager via

Règles et limitations du chargement en masse XML (SQLXML 4.0)

  • Article

S’applique à : SQL ServerAzure SQL Database

Lorsque vous utilisez le chargement en masse XML, vous devez connaître les indications et les limitations suivantes :

  • Les schémas insérés ne sont pas pris en charge.

    Si vous possédez un schéma inséré dans le document XML source, le chargement en masse XML ignore ce schéma. Vous spécifiez le schéma de mappage pour le chargement en masse XML externe aux données XML. Vous ne pouvez pas spécifier le schéma de mappage sur un nœud à l’aide de l’attribut xmlns="x :schema ».

  • Le système vérifie qu'un document XML est correct, mais ne le valide pas.

    Le chargement en masse XML vérifie le document XML pour déterminer s’il est bien formé, c’est-à-dire s’assurer que le code XML est conforme aux exigences de syntaxe de la recommandation XML 1.0 du World Wide Web Consortium. Si le document n'est pas correct, le chargement en masse XML annule le traitement et retourne une erreur. La seule exception à ceci est lorsque le document est un fragment (par exemple, le document n'a aucun élément racine unique), auquel cas le chargement en masse XML chargera le document.

    Le chargement en masse XML ne valide pas le document par rapport à tout schéma de données XML ou DTD qui est défini ou référencé dans le fichier de données XML. De plus, le chargement en masse XML ne valide pas le fichier de données XML par rapport au schéma de mappage fourni.

  • Toutes informations de prologue XML sont ignorées.

    Le chargement en masse XML ignore toutes les informations avant et après l’élément <racine> du document XML. Par exemple, le chargement en masse XML ignore toutes les déclarations XML, les définitions DTD internes, les références DTD externes, les commentaires, etc.

  • Si vous possédez un schéma de mappage qui définit une relation clé primaire/clé étrangère entre deux tables (par exemple, entre Customer et CustOrder), la table avec la clé primaire doit être décrite en premier dans le schéma. La table avec la colonne de clé étrangère doit apparaître ultérieurement dans le schéma. La raison en est que l’ordre dans lequel les tables sont identifiées dans le schéma est l’ordre utilisé pour les charger dans la base de données. Par exemple, le schéma XDR suivant génère une erreur lorsqu’il est utilisé dans le chargement en bloc XML, car l’élément <Order> est décrit avant l’élément< Customer.> La colonne CustomerID dans CustOrder est une colonne de clé étrangère qui fait référence à la colonne de clé primaire CustomerID dans la table Cust.

    <?xml version="1.0" ?>  
<Schema xmlns="urn:schemas-microsoft-com:xml-data"   
        xmlns:dt="urn:schemas-microsoft-com:xml:datatypes"    
        xmlns:sql="urn:schemas-microsoft-com:xml-sql" >  

    <ElementType name="Order" sql:relation="CustOrder" >  
      <AttributeType name="OrderID" />  
      <AttributeType name="CustomerID" />  
      <attribute type="OrderID" />  
      <attribute type="CustomerID" />  
    </ElementType>  

   <ElementType name="CustomerID" dt:type="int" />  
   <ElementType name="CompanyName" dt:type="string" />  
   <ElementType name="City" dt:type="string" />  

   <ElementType name="root" sql:is-constant="1">  
      <element type="Customers" />  
   </ElementType>  
   <ElementType name="Customers" sql:relation="Cust"   
                     sql:overflow-field="OverflowColumn"  >  
      <element type="CustomerID" sql:field="CustomerID" />  
      <element type="CompanyName" sql:field="CompanyName" />  
      <element type="City" sql:field="City" />  
      <element type="Order" >   
           <sql:relationship  
               key-relation="Cust"  
                key="CustomerID"  
                foreign-key="CustomerID"  
                foreign-relation="CustOrder" />  
      </element>  
   </ElementType>  
</Schema>

  • Si le schéma ne spécifie pas de colonnes de dépassement à l’aide de l’annotation sql :overflow-field , le chargement en masse XML ignore les données présentes dans le document XML, mais n’est pas décrite dans le schéma de mappage.

    Le chargement en masse XML applique le schéma de mappage que vous avez spécifié toutes les fois qu'il rencontre des balises connues dans le flux de données XML. Il ignore les données qui sont présentes dans le document XML mais qui ne sont pas décrites dans le schéma. Par exemple, supposons que vous disposez d’un schéma de mappage qui décrit un élément Customer>.< Le fichier de données XML a une <balise racine AllCustomers> (qui n’est pas décrite dans le schéma) qui entoure tous les< éléments Customer> :

    <AllCustomers>  
  <Customer>...</Customer>  
  <Customer>...</Customer>  
   ...  
</AllCustomers>

    Dans ce cas, le chargement en masse XML ignore l’élément <AllCustomers> et commence le mappage à l’élément <Customer>. Le chargement en masse XML ignore les éléments qui ne sont pas décrits dans le schéma mais qui sont présents dans le document XML.

    Considérez un autre fichier de données source XML qui contient des éléments Order>.< Ces éléments ne sont pas décrits dans le schéma de mappage :

    <AllCustomers>  
  <Customer>...</Customer>  
    <Order> ... </Order>  
    <Order> ... </Order>  
     ...  
  <Customer>...</Customer>  
    <Order> ... </Order>  
    <Order> ... </Order>  
     ...  
  ...  
</AllCustomers>

    Le chargement en masse XML ignore ces éléments Order>.< Toutefois, si vous utilisez l’annotation sql :overflow-fielddans le schéma pour identifier une colonne en tant que colonne de dépassement, le chargement en masse XML stocke toutes les données nonumées dans cette colonne.

  • Les sections CDATA et les références d'entité sont traduites en chaînes équivalentes avant d'être stockées dans la base de données.

    Dans cet exemple, une section CDATA encapsule la valeur de l’élément <City> . Xml Bulk Load extrait la valeur de chaîne (« NY ») avant d’insérer l’élément <City> dans la base de données.

    <City><![CDATA[NY]]> </City>

    Le chargement en masse XML ne conserve pas les références d'entité.

  • Si le schéma de mappage spécifie la valeur par défaut pour un attribut et que les données de source XML ne contiennent pas cet attribut, le chargement en masse XML utilise la valeur par défaut.

    L’exemple de schéma XDR suivant affecte une valeur par défaut à l’attribut HireDate :

    <?xml version="1.0" ?>  
<Schema xmlns="urn:schemas-microsoft-com:xml-data"   
        xmlns:dt="urn:schemas-microsoft-com:xml:datatypes"    
        xmlns:sql="urn:schemas-microsoft-com:xml-sql" >  
   <ElementType name="root" sql:is-constant="1">  
      <element type="Customers" />  
   </ElementType>  

   <ElementType name="Customers" sql:relation="Cust3" >  
      <AttributeType name="CustomerID" dt:type="int"  />  
      <AttributeType name="HireDate"  default="2000-01-01" />  
      <AttributeType name="Salary"   />  

      <attribute type="CustomerID" sql:field="CustomerID" />  
      <attribute type="HireDate"   sql:field="HireDate"  />  
      <attribute type="Salary"     sql:field="Salary"    />  
   </ElementType>  
</Schema>

    Dans ces données XML, l’attribut HireDate est manquant dans le deuxième <élément Customers>. Lorsque le chargement en masse XML insère le deuxième <élément Customers> dans la base de données, il utilise la valeur par défaut spécifiée dans le schéma.

    <ROOT>  
  <Customers CustomerID="1" HireDate="1999-01-01" Salary="10000" />  
  <Customers CustomerID="2" Salary="10000" />  
</ROOT>

  • L’annotation sql :url-encode n’est pas prise en charge :

    Vous ne pouvez pas spécifier une URL dans l'entrée de données XML et vous attendre à ce que le chargement en masse lise les données à cet emplacement.

    Les tables qui sont identifiées dans le schéma de mappage sont créées (la base de données doit exister). Si une ou plusieurs des tables existent déjà dans la base de données, la propriété SGDropTables détermine si ces tables préexistantes doivent être supprimées et recréées.

  • Si vous spécifiez la propriété SchemaGen (par exemple, SchemaGen = true), les tables identifiées dans le schéma de mappage sont créées. Mais SchemaGen ne crée aucune contrainte (par exemple, les contraintes PRIMARY KEY/FOREIGN KEY) sur ces tables à une exception près : si les nœuds XML qui constituent la clé primaire dans une relation sont définis comme ayant un type XML d’ID (autrement dit, type="xsd :ID » pour XSD) ET que la propriété SGUseID a la valeur True pour SchemaGen, alors non seulement les clés primaires créées à partir des nœuds typés d’ID, mais les relations clé primaire/clé étrangère sont créées à partir des relations de schéma de mappage.

  • SchemaGen n’utilise pas de facettes et d’extensions de schéma XSD pour générer le schéma SQL Server relationnel.

  • Si vous spécifiez la propriété SchemaGen (par exemple, SchemaGen = true) sur le chargement en bloc, seules les tables (et non les vues du nom partagé) spécifiées sont mises à jour.

  • SchemaGen fournit uniquement des fonctionnalités de base pour générer le schéma relationnel à partir d’un XSD annoté. L'utilisateur doit modifier manuellement les tables générées, si nécessaire.

  • Là où plusieurs relations existent entre les tables, SchemaGen tente de créer une relation unique qui inclut toutes les clés impliquées entre les deux tables. Cette limitation peut être la cause d’une erreur Transact-SQL.

  • Lorsque vous chargez en masse des données XML dans une base de données, il doit y avoir au moins un attribut ou élément enfant dans le schéma de mappage qui est mappé à une colonne de base de données.

  • Si vous insérez des valeurs de date à l'aide du chargement en masse XML, les valeurs doivent être spécifiées au format (-)SSAA-MM-JJ((+-)TZ). Ceci est le format XSD standard pour la date.

  • Certains indicateurs de propriété ne sont pas compatibles avec d'autres indicateurs de propriété. Par exemple, le chargement en bloc ne prend pas en charge Ignoreduplicatekeys=true avec Keepidentity=false. Lorsque Keepidentity=false, le chargement en bloc s’attend à ce que le serveur génère les valeurs de clé. Les tables doivent avoir une contrainte IDENTITY sur la clé. Le serveur ne génère pas de clés dupliquées, ce qui signifie qu’il n’est pas nécessaire que les ignoreduplicatekeys soient définies sur true. Ignoreduplicatekeys doit être défini sur true uniquement lors du chargement des valeurs de clé primaire à partir des données entrantes dans une table qui comporte des lignes et il existe un risque de conflit de valeurs de clé primaire.