Compartir a través de


Instrucciones y limitaciones de la carga masiva XML (SQLXML 4.0)

Se aplica a:SQL ServerAzure SQL Database

Antes de usar la carga masiva XML, debe familiarizarse con las siguientes limitaciones e instrucciones:

  • No se admiten los esquemas insertados.

    Si tiene un esquema insertado en el documento XML de origen, la carga masiva XML omite dicho esquema. Debe especificar el esquema de asignación para la carga masiva XML de forma externa con respecto a los datos XML. No se puede especificar el esquema de asignación en un nodo mediante el atributo xmlns="x:schema".

  • Se comprueba que el formato de un documento XML sea correcto, pero no se valida el documento.

    Carga masiva XML comprueba el documento XML para determinar si está bien formado, para asegurarse de que el XML cumple los requisitos de sintaxis de la recomendación XML 1.0 de World Wide Web Consortium. Si el documento no tiene el formato correcto, la carga masiva XML cancela el procesamiento y devuelve un error. La única excepción a esta regla es que el documento sea un fragmento (por ejemplo, el documento no tiene ningún elemento raíz único), en cuyo caso la carga masiva XML cargará el documento.

    La carga masiva XML no valida el documento con respecto a cualquier esquema de datos XML o esquema DTD que se defina o al que se haga referencia dentro del archivo de datos XML. Además, la carga masiva XML no valida el archivo de datos XML en el esquema de asignación proporcionado.

  • Se omite cualquier información de prólogo XML.

    La carga masiva XML omite toda la información antes y después del <elemento raíz> en el documento XML. Por ejemplo, la carga masiva XML omite todas las declaraciones XML, definiciones DTD internas, referencias DTD externas, todos los comentarios, etc.

  • Si tiene un esquema de asignación que define una relación de clave principal y clave externa entre dos tablas (como Customer y CustOrder), la tabla con la clave principal debe describirse en primer lugar en el esquema. La tabla con la columna de clave externa debe aparecer posteriormente en el esquema. El motivo es que el orden en que se identifican las tablas en el esquema es el orden que se usa para cargarlas en la base de datos. Por ejemplo, el siguiente esquema XDR producirá un error cuando se use en carga masiva XML porque el <elemento Order> se describe antes del <elemento Customer> . La columna CustomerID de CustOrder es una columna de clave externa que hace referencia a la columna de clave principal CustomerID de la tabla 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 el esquema no especifica columnas de desbordamiento mediante la anotación sql:overflow-field , la carga masiva XML omite los datos presentes en el documento XML, pero no se describe en el esquema de asignación.

    La carga masiva XML aplica el esquema de asignación especificado cada vez que encuentra etiquetas conocidas en el flujo de datos XML. Omite los datos presentes en el documento XML que no se describen en el esquema. Por ejemplo, supongamos que tiene un esquema de asignación que describe un <elemento Customer> . El archivo de datos XML tiene una <etiqueta raíz AllCustomers> (que no se describe en el esquema) que incluye todos los <elementos Customer> :

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

    En este caso, la carga masiva XML omite el <elemento AllCustomers> y comienza la asignación en el <elemento Customer> . La carga masiva XML omite los elementos que no se describen en el esquema pero que están presentes en el documento XML.

    Considere otro archivo de datos de origen XML que contenga <elementos Order> . Estos elementos no se describen en el esquema de asignación:

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

    La carga masiva XML omite estos <elementos Order> . Pero si usa la anotación sql:overflow-fielden el esquema para identificar una columna como una columna de desbordamiento, la carga masiva XML almacena todos los datos no consumidos en esta columna.

  • Las secciones CDATA y las referencias a entidades se traducen a sus cadenas equivalentes antes de almacenarse en la base de datos.

    En este ejemplo, una sección CDATA ajusta el valor del <elemento City> . Carga masiva XML extrae el valor de cadena ("NY") antes de insertar el <elemento City> en la base de datos.

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

    La carga masiva XML no conserva las referencias a entidades.

  • Si el esquema de asignación especifica el valor predeterminado de un atributo y los datos de origen XML no contienen dicho atributo, la carga masiva XML usa el valor predeterminado.

    El esquema XDR de ejemplo siguiente asigna un valor predeterminado al atributo 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>  
    

    En estos datos XML, falta el atributo HireDate del segundo <elemento Customers> . Cuando carga masiva XML inserta el segundo <elemento Customers> en la base de datos, usa el valor predeterminado especificado en el esquema.

    <ROOT>  
      <Customers CustomerID="1" HireDate="1999-01-01" Salary="10000" />  
      <Customers CustomerID="2" Salary="10000" />  
    </ROOT>  
    
  • No se admite la anotación sql:url-encode :

    No puede especificar una dirección URL en la entrada de datos XML y esperar que la carga masiva lea los datos de dicha ubicación.

    Se crean las tablas que se identifican en el esquema de asignación (la base de datos debe existir). Si ya existe una o varias de las tablas en la base de datos, la propiedad SGDropTables determina si estas tablas preexistentes se van a quitar y volver a crear.

  • Si especifica la propiedad SchemaGen (por ejemplo, SchemaGen = true), se crean las tablas identificadas en el esquema de asignación. Pero SchemaGen no crea ninguna restricción (como las restricciones PRIMARY KEY/FOREIGN KEY) en estas tablas con una excepción: si los nodos XML que constituyen la clave principal de una relación se definen como tener un tipo XML de id. (es decir, type="xsd:ID" para XSD) Y la propiedad SGUseID se establece en True para SchemaGen, después, no solo se crean claves principales a partir de los nodos con tipo de identificador, sino que las relaciones de clave principal/clave externa se crean a partir de las relaciones de esquema de asignación.

  • SchemaGen no usa facetas y extensiones de esquema XSD para generar el esquema de SQL Server relacional.

  • Si especifica la propiedad SchemaGen (por ejemplo, SchemaGen = true) en carga masiva, solo se actualizan las tablas (y no las vistas del nombre compartido) especificadas.

  • SchemaGen solo proporciona funcionalidad básica para generar el esquema relacional a partir de XSD anotado. El usuario debe modificar las tablas generadas manualmente si es preciso.

  • Cuando existe más de una relación entre tablas, SchemaGen intenta crear una única relación que incluya todas las claves implicadas entre las dos tablas. Esta limitación puede ser la causa de un error de Transact-SQL.

  • Al realizar cargas masivas de datos XML en una base de datos, debe haber al menos un atributo o elemento secundario en el esquema de asignación que esté asignado a una columna de base de datos.

  • Si está insertando valores de fecha mediante la carga masiva XML, estos valores deben especificarse con el formato (-)CCYY-MM-DD((+-)TZ). Se trata del formato XSD estándar para la fecha.

  • Algunas marcas de propiedad no son compatibles con otras. Por ejemplo, la carga masiva no admite Ignoreduplicatekeys=true junto con Keepidentity=false. Cuando Keepidentity=false, la carga masiva espera que el servidor genere los valores de clave. Las tablas deben tener una restricción IDENTITY en la clave. El servidor no generará claves duplicadas, lo que significa que no es necesario establecer ignoreduplicatekeys en true. Ignoreduplicatekeys debe establecerse en true solo cuando se cargan valores de clave principal de los datos entrantes en una tabla que tiene filas y existe la posibilidad de que entren en conflicto los valores de clave principal.