Dela via

Använda EXPLICIT läge med FOR XML

  • Artikel

gäller för:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

Som beskrivs i artikeln Att konstruera XML med hjälp av FOR XML, ger RAW- och AUTO-läge inte mycket kontroll över formen på XML som genereras från ett frågeresultat. Explicit läge ger dock den största flexibiliteten när det gäller att generera den XML du vill ha från ett frågeresultat.

Frågan i EXPLICIT-läge måste skrivas på ett specifikt sätt så att ytterligare information om nödvändig XML, till exempel förväntad kapsling i XML, uttryckligen anges som en del av sökningen. Beroende på vilken XML du begär kan det vara besvärligt att skriva EXPLICIT-lägesfrågor. Du kanske upptäcker att Använda PATH-läge med kapsling är ett enklare alternativ till att skriva EXPLICIT-lägesfrågor.

Eftersom du beskriver den XML som du vill använda som en del av frågan i EXPLICIT-läge måste du se till att den genererade XML-koden är väl utformad och giltig.

Raderuppsättningsbearbetning i EXPLICIT läge

Läget EXPLICIT omvandlar det resulterande radsättet som är resultatet av frågekörning till ett XML-dokument. För att EXPLICIT läge ska kunna producera XML-dokumentet måste raduppsättningen ha ett visst format. Detta kräver att du skriver SELECT-frågan för att skapa raduppsättningen, den universella tabellen, med ett specifikt format så att bearbetningslogik sedan kan producera den XML du vill ha.

Först måste frågan skapa följande två metadatakolumner:

  • Den första kolumnen måste ange taggnummer, heltalstyp, för det aktuella elementet och kolumnnamnet måste vara Tag. Frågan måste ange ett unikt taggnummer för varje element som ska konstrueras från raduppsättningen.

  • Den andra kolumnen måste ange ett taggnummer för det överordnade elementet och det här kolumnnamnet måste vara Överordnad. På så sätt tillhandahåller kolumnerna Tagg och Förälder hierarkiinformation.

Dessa metadatakolumnvärden, tillsammans med informationen i kolumnnamnen, används för att skapa den XML som du vill använda. Frågan måste ange kolumnnamn på ett specifikt sätt. Observera också att kolumnen 0 eller NULL i kolumnen Parent anger att motsvarande element inte har något överordnat element. Elementet läggs till i XML som ett element på den översta nivån.

För att förstå hur den universella tabell som genereras av en fråga bearbetas för att generera XML-resultat antar du att du har skrivit en fråga som skapar den här universella tabellen:

Exempel på universell tabell.

Observera följande om den här universella tabellen:

  • De första två kolumnerna är Tagg och Förälder och är metakolumner. Dessa värden bestämmer hierarkin.

  • Kolumnnamnen anges på ett visst sätt, enligt beskrivningen senare i den här artikeln.

  • Vid generering av XML från den här universella tabellen partitioneras data i den här tabellen lodrätt i kolumngrupper. Gruppering bestäms baserat på värdet Tag och kolumnnamnen. När du skapar XML väljer bearbetningslogik en grupp kolumner för varje rad och skapar ett element. Följande gäller i det här exemplet:

    • För Tagga kolumnvärde 1 på den första raden bildar kolumnerna vars namn innehåller samma taggnummer Customer!1!cid och Customer!1!name, en grupp. Dessa kolumner används för att bearbeta raden, och du kanske har märkt att formen på det genererade elementet är <Customer id=... name=...>. Format för kolumnnamn beskrivs senare i den här artikeln.

    • För rader med Tag kolumnvärde 2 bildar kolumner Order!2!id och Order!2!date en grupp som sedan används för att konstruera element <Order id=... date=... />.

    • För rader med Tag kolumnvärde 3 bildar kolumnerna OrderDetail!3!id!id och OrderDetail!3!pid!idref en grupp. Var och en av dessa rader genererar ett element, <OrderDetail id=... pid=...>, från dessa kolumner.

  • Vid generering av XML-hierarki bearbetas raderna i ordning. XML-hierarkin bestäms enligt följande:

    • Den första raden anger Tag värdet 1 och parent värdet NULL. Därför läggs motsvarande element, <Customer> element, till som ett element på den översta nivån i XML-koden.

      <Customer cid="C1" name="Janine">

    • Den andra raden identifierar Tag-värdet 2 och överordnat värde 1. Därför läggs elementet <Order> till som ett underordnat element till elementet <Customer>.

      <Customer cid="C1" name="Janine">
   <Order id="O1" date="1/20/1996">

    • De nästkommande två raderna identifierar Tag värde 3 och Förälder värde 2. Därför läggs de två elementen, <OrderDetail>-elementen, till som underordnade till <Order>-elementet.

      <Customer cid="C1" name="Janine">
   <Order id="O1" date="1/20/1996">
      <OrderDetail id="OD1" pid="P1"/>
      <OrderDetail id="OD2" pid="P2"/>

    • Den sista raden identifierar 2 som tagg nummer och 1 som Parent tagg. Därför läggs ett annat <Order>-element som en underordnad till det <Customer>-överenordnade elementet.

      <Customer cid="C1" name="Janine">
   <Order id="O1" date="1/20/1996">
      <OrderDetail id="OD1" pid="P1"/>
      <OrderDetail id="OD2" pid="P2"/>
   </Order>
   <Order id="O2" date="3/29/1997">
</Customer>

För att sammanfatta, värdena i Tag och Överordnad metakolumner, informationen som anges i kolumnnamnen, och den korrekta ordningen på raderna producerar den XML du vill ha när du använder i EXPLICIT-läge.

Universell tabellradens ordning

När du skapar XML bearbetas raderna i den universella tabellen i ordning. För att hämta rätt underordnade instanser som är associerade med deras föräldrar måste raderna i raduppsättningen därför ordnas så att varje föräldranod omedelbart följs av dess underordnade.

Ange kolumnnamn i en universell tabell

När du skriver explicita lägesfrågor måste kolumnnamn i den resulterande raduppsättningen anges med det här formatet. De tillhandahåller transformeringsinformation inklusive element- och attributnamn och annan ytterligare information som anges med hjälp av direktiv.

Det här är det allmänna formatet:

ElementName!TagNumber!AttributeName!Directive

Följande är beskrivningen av delarna i formatet.

  • ElementName

    Den resulterande allmänna identifieraren för elementet. Om till exempel Kunder anges som ElementNamegenereras <Customers>-elementet.

  • TagNumber

    Ett unikt taggvärde som tilldelats ett element. Det här värdet, med hjälp av de två metadatakolumnerna, Tag och Parent, avgör kapslingen av elementen i den resulterande XML-koden.

  • Attributnamn

    Anger namnet på attributet som ska skapas i den angivna ElementName-. Det här är beteendet om direktiv inte har angetts.

    Om direktiv har angetts och det är xml, cdataeller element, kommer detta värde att användas för att konstruera ett barn-element av ElementName, och kolumnvärdet läggs till i det.

    Om du anger -direktivetkan AttributeName vara tom. Till exempel ElementName! TagNumber!! Direktiv. I det här fallet finns kolumnvärdet direkt i ElementName-.

  • direktiv

    Direktiv är valfritt och du kan använda det för att ange ytterligare information för att skapa XML. direktiv har två syften.

    • Ett av syftena är att koda värden som ID, IDREF och IDREFS. Du kan ange ID, IDREFoch IDREFS nyckelord som direktiv. Dessa direktiv skriver över attributtyperna. På så sätt kan du skapa länkar inom dokument.

    • Du kan också använda direktiv för att ange hur du mappar strängdata till XML. döljer elementen, , elementxsinil, , xml, , xmltextoch , cdata-nyckelorden kan användas som direktiv. döljer-direktivet döljer noden. Detta är användbart när du endast hämtar värden i sorteringssyfte, men du inte vill ha dem i den resulterande XML-koden.

    -elementet-direktivet genererar ett inneslutet element i stället för ett attribut. Inneslutna data kodas som en entitet. Till exempel blir <-tecknet <. För NULL-kolumnvärden genereras inget element. Om du vill att ett element ska genereras för null-kolumnvärden kan du ange elementxsinil-direktivet. Detta genererar ett element som har attributet xsi:nil=TRUE.

    XML--direktivet är detsamma som ett element-direktivet, förutom att ingen entitetskodning sker. -elementet-direktivet kan kombineras med ID, IDREFeller IDREFS, medan xml--direktivet inte tillåts med något annat direktiv, förutom dölja.

    Direktivet cdata innehåller data genom att omsluta dem med ett CDATA-avsnitt. Innehållet är inte entitetskodat. Den ursprungliga datatypen måste vara en texttyp som varchar, nvarchar, texteller ntext. Det här direktivet kan endast användas med dölja. När det här direktivet används får AttributeName inte anges.

    Det är tillåtet att kombinera direktiv mellan dessa två grupper i de flesta fall, men det är inte tillåtet att kombinera dem sinsemellan.

Om Direktiv och AttributeName inte har angetts, till exempel Customer!1, är ett -element direktiv underförstått, till exempel Customer!1!! elementet, och kolumndata finns i ElementName-.

Om xmltext--direktivet anges omsluts kolumninnehållet i en enda tagg som är integrerad med resten av dokumentet. Det här direktivet är användbart för att hämta överflödig, oanvänd XML-data som lagras i en kolumn med hjälp av OPENXML. Mer information finns i OPENXML (SQL Server).

Om AttributeName anges ersätts taggnamnet med det angivna namnet. Annars läggs attributet till i den aktuella listan över attribut för de omslutande elementen genom att innehållet läggs till i början av inneslutningen utan entitetskodning. Kolumnen med det här direktivet måste vara en texttyp, till exempel varchar, nvarchar, char, nchar, texteller ntext. Det här direktivet kan endast användas med dölja. Det här direktivet är användbart när du hämtar spilldata som lagras i en kolumn. Om innehållet inte är en välformulerad XML är beteendet odefinierat.

Nästa steg

Följande exempel illustrerar användningen av EXPLICIT-läge.

Se även