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 au niveau d’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’il 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> dans le 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 masse 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 toutes les données présentes dans le document XML, mais qui ne sont pas décrites 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 inclut 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.

    Prenons l’exemple d’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 de capacité, le chargement en masse XML stocke toutes les données non utilisé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> . Le chargement en masse XML 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 (comme les contraintes PRIMARY KEY/FOREIGN KEY) sur ces tables à une exception près : si les nœuds XML qui constituent la clé primaire d’une relation sont définis comme ayant un type XML d’ID (c’est-à-dire type="xsd:ID » pour XSD) ET si la propriété SGUseID a la valeur True pour SchemaGen, alors non seulement les clés primaires sont créées à partir des nœuds typés id, mais les relations clé primaire/clé étrangère sont créées à partir de 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 de SQL Server relationnel.

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

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

  • Lorsqu’il existe plusieurs relations 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 à l’origine 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 masse ne prend pas en charge Ignoreduplicatekeys=true avec Keepidentity=false. Quand Keepidentity=false, le chargement en masse 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 en double, ce qui signifie qu’il n’est pas nécessaire de définir ignoreduplicatekeys sur true. Ignoreduplicatekeys doit être défini sur true uniquement lors du chargement de valeurs de clé primaire à partir des données entrantes dans une table contenant des lignes et pouvant entraîner un conflit de valeurs de clé primaire.