Partager via


Recommandations et limitations du chargement en bloc XML (SQLXML 4.0)

Lorsque vous utilisez le chargement en bloc XML, vous devez être familiarisé avec les instructions et limitations suivantes :

  • Les schémas inline ne sont pas pris en charge.

    Si vous avez un schéma inline dans le document XML source, le chargement en masse XML XML ignore ce schéma. Vous spécifiez le schéma de mappage pour le chargement en bloc 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 ».

  • Un document XML est vérifié pour être bien formé, mais il n’est pas validé.

    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 bien formé, le chargement en masse XML annule le traitement et retourne une erreur. La seule exception à ceci est que le document est un fragment (par exemple, le document n’a pas d’élément racine unique), auquel cas le chargement en masse XML charge le document.

    Le chargement en masse XML ne valide pas le document en ce qui concerne tout schéma XML-Data ou DTD défini ou référencé dans le fichier de données XML. En outre, le chargement en masse XML ne valide pas le fichier de données XML par rapport au schéma de mappage fourni.

  • Toutes les 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 les déclarations XML, les définitions DTD internes, les références DTD externes, les commentaires, et ainsi de suite.

  • Si vous avez 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 clé primaire CustomerID de 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é chaque fois qu’il rencontre des balises connues dans le flux de données XML. Il ignore les données présentes dans le document XML, mais n’est pas décrite 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 de dépassement de capacité, le chargement en bloc XML stocke toutes les données nonumées dans cette colonne.

  • Les sections CDATA et les références d’entité sont traduites en leurs équivalents de chaîne avant qu’elles ne soient 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 bloc XML ne conserve pas les références d’entité.

  • Si le schéma de mappage spécifie la valeur par défaut d’un attribut et que les données de source XML ne contiennent pas cet attribut, le chargement en bloc 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 attendez à ce que le chargement en bloc lise les données à partir de cet emplacement.

    Les tables 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ù 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 la cause d’une erreur Transact-SQL.

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

  • Si vous insérez des valeurs de date à l’aide du chargement en bloc XML, les valeurs doivent être spécifiées au format (-)CCYY-MM-DD((+-)TZ). Il s’agit du format XSD standard pour la date.

  • Certains indicateurs de propriété ne sont pas compatibles avec d’autres indicateurs de propriété. Par exemple, la charge en bloc ne prend pas en charge Ignoreduplicatekeys=true avec Keepidentity=false. Quand Keepidentity=false, le chargement en bloc s’attend à ce que le serveur génère les valeurs de clé. Les tables doivent avoir une IDENTITY contrainte 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 Ignoreduplicatekeys d’être défini truesur . Ignoreduplicatekeys doit être défini uniquement true lorsque vous chargez des valeurs de clé primaire à partir des données entrantes dans une table qui comporte des lignes et qu’il existe un risque de conflit de valeurs de clé primaire.