Condividi tramite


Linee guida e limitazioni per il caricamento bulk XML (SQLXML 4.0)

Quando si utilizza il caricamento bulk XML, è consigliabile disporre di una certa familiarità con le linee guida e le limitazioni seguenti:

  • Gli schemi inline non sono supportati.

    Se nel documento XML di origine è presente uno schema inline, questo viene ignorato dal caricamento bulk XML. È necessario specificare lo schema di mapping per il caricamento bulk XML come esterno ai dati XML. Non è possibile specificare lo schema di mapping in corrispondenza di un nodo tramite l'attributo xmlns="x:schema".

  • Un documento XML viene controllato per verificare che utilizzi un formato corretto, ma non viene convalidato.

    Il caricamento bulk XML controlla il documento XML per determinare se è nel formato corretto, ovvero per garantire che i dati XML rispondano ai requisiti di sintassi della specifica XML 1.0 del World Wide Web Consortium. Se il formato del documento non è corretto, il caricamento bulk XML annulla l'elaborazione e restituisce un errore. L'unica eccezione a questo comportamento è costituita dal caso in cui il documento è un frammento, ad esempio non dispone di un singolo elemento radice. In questo caso, il documento verrà caricato.

    Il caricamento bulk XML non convalida il documento rispetto ad alcuno schema dati XML o DTD definito o a cui si fa riferimento all'interno del file di dati XML. Il caricamento bulk XML, inoltre, non convalida il file di dati XML rispetto allo schema di mapping fornito.

  • Vengono ignorate tutte le informazioni sui prologhi XML.

    Il caricamento bulk XML ignora tutte le informazioni prima e dopo l'elemento <root> nel documento XML. Il caricamento bulk XML, ad esempio, ignora qualsiasi dichiarazione XML, qualsiasi definizione DTD interna e tutti i riferimenti DTD esterni, i commenti e così via.

  • Se è presente uno schema di mapping che definisce una relazione di chiave primaria/chiave esterna tra due tabelle, ad esempio tra Customer e CustOrder, la tabella con la chiave primaria deve essere descritta per prima nello schema. La tabella con la colonna di chiave esterna deve essere visualizzata come successiva nello schema. Ciò è dovuto al fatto che l'ordine di identificazione delle tabelle nello schema corrisponde all'ordine utilizzato per caricarle nel database.Lo schema XDR seguente, ad esempio, produrrà un errore se utilizzato nel caricamento bulk XML, in quanto l'elemento <Order> viene descritto prima dell'elemento <Customer>. La colonna CustomerID in CustOrder è una colonna di chiave esterna che fa riferimento alla colonna di chiave primaria CustomerID nella tabella 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>
    
  • Se lo schema non specifica colonne di overflow tramite l'annotazione sql:overflow-field, il caricamento bulk XML ignora tutti i dati presenti nel documento XML ma che non sono descritti nello schema di mapping.

    Il caricamento bulk XML applica lo schema di mapping specificato ogni volta che rileva tag noti nel flusso di dati XML e ignora i dati presenti nel documento XML ma che non sono descritti nello schema. Si supponga, ad esempio, di disporre di uno schema di mapping che descrive un elemento <Customer>. Nel file di dati XML è presente un tag radice <AllCustomers>, non descritto nello schema, che include tutti gli elementi <Customer>:

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

    In questo caso, il caricamento bulk XML ignora l'elemento <AllCustomers> e avvia il mapping in corrispondenza dell'elemento <Customer>. Il caricamento bulk XML ignora gli elementi non descritti nello schema ma che sono presenti nel documento XML.

    Si consideri un altro file di dati XML di origine contenente elementi <Order>. Tali elementi non vengono descritti nello schema di mapping:

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

    Il caricamento bulk XML ignora questi elementi <Order>. Se, tuttavia, si utilizza l'annotazione sql:overflow-field nello schema per identificare una colonna come colonna di overflow, il caricamento bulk XML archivia tutti i dati non utilizzati in questa colonna.

  • Le sezioni CDATA e i riferimenti a entità vengono convertiti nei rispettivi equivalenti in formato stringa prima di essere archiviati nel database.

    In questo esempio una sezione CDATA incapsula il valore per l'elemento <City>. Il caricamento bulk XML estrae il valore stringa ("NY") prima di inserire l'elemento <City> nel database.

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

    Il caricamento bulk XML non mantiene i riferimenti alle entità.

  • Se lo schema di mapping specifica il valore predefinito per un attributo e i dati di origine XML non contengono tale attributo, il caricamento bulk XML utilizza il valore predefinito.

    Nello schema XDR di esempio seguente viene assegnato un valore predefinito all'attributo 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>
    

    In questi dati XML l'attributo HireDate risulta mancante nel secondo elemento <Customers>. Quando il caricamento bulk XML inserisce il secondo elemento <Customers> nel database, utilizza il valore predefinito specificato nello schema.

    <ROOT>
      <Customers CustomerID="1" HireDate="1999-01-01" Salary="10000" />
      <Customers CustomerID="2" Salary="10000" />
    </ROOT>
    
  • L'annotazione sql:url-encode non è supportata.

    Non è possibile specificare un URL nei dati XML di input e prevedere che il caricamento bulk legga i dati da tale posizione.

    Vengono create le tabelle identificate nello schema di mapping (il database deve essere presente). Se una o più tabelle sono già presenti nel database, la proprietà SGDropTables determina se tali tabelle preesistenti devono essere eliminate e ricreate.

  • Se si specifica la proprietà SchemaGen, ad esempio SchemaGen = true, le tabelle identificate nello schema di mapping vengono create. SchemaGen, tuttavia, non crea alcun vincolo, ad esempio i vincoli PRIMARY KEY/FOREIGN KEY, in tali tabelle, ad eccezione di un caso: se i nodi XML che costituiscono la chiave primaria in una relazione vengono definiti come associati a un tipo XML di ID, ovvero type="xsd:ID" per XSD, E se la proprietà SGUseID è impostata su True per SchemaGen, non solo vengono create chiavi primarie dai nodi con tipo di ID, ma vengono anche create relazioni di chiave primaria/chiave esterna dalle relazioni dello schema di mapping.

  • SchemaGen non utilizza facet ed estensioni dello schema XSD per generare lo schema SQL Server relazionale.

  • Se si specifica la proprietà SchemaGen, ad esempio SchemaGen = true, nel caricamento bulk, verranno aggiornate solo le tabelle specificate e non le viste con nome condiviso.

  • SchemaGen fornisce solo la funzionalità di base per la generazione dello schema relazionale da XSD con annotazioni. Se necessario, l'utente deve modificare manualmente le tabelle generate.

  • Quando tra tabelle sussistono più relazioni,SchemaGen tenta di creare una singola relazione che include tutte le chiavi interessate tra le due tabelle. Questa limitazione può essere la causa di un errore Transact-SQL.

  • Quando si esegue il caricamento bulk di dati XML in un database, deve essere presente almeno un attributo o un elemento figlio nello schema di mapping mappato a una colonna del database.

  • Se si inseriscono valori di data tramite il caricamento bulk XML, i valori devono essere specificati nel formato (-)AAAA-MM-GG((+-)FO). Si tratta del formato XSD standard per la data.

  • Alcuni flag della proprietà non sono compatibili con altri flag della proprietà stessa. Il caricamento bulk, ad esempio, non supporta il flag Ignoreduplicatekeys=true utilizzato con Keepidentity=false. Nel caso in cui Keepidentity=false, durante il caricamento bulk si prevede che il server generi i valori della chiave. Nelle tabelle deve essere presente un vincolo IDENTITY sulla chiave. Il server non genererà chiavi duplicate. In questo modo non sarà necessario impostare Ignoreduplicatekeys su true. Ignoreduplicatekeys deve essere impostato su true solo quando viene eseguito il caricamento di valori di chiave primaria dai dati in entrata in una tabella con righe ed è presente un conflitto potenziale di valori di chiave primaria.