Share via


Richtlinien für die Verwendung der FOR XML-Klausel

Die FOR XML-Klausel kann in Abfragen der obersten Ebene sowie in Unterabfragen verwendet werden. Die FOR XML-Klausel der obersten Ebene kann nur in der SELECT-Anweisung verwendet werden. In Unterabfragen kann FOR XML in den INSERT-, UPDATE- und DELETE-Anweisungen verwendet werden. Die Klausel kann auch in Zuweisungsanweisungen verwendet werden. Beispiel:

DECLARE @x xml
SET @x = (SELECT *
FROM Sales.Customer
FOR XML AUTO, TYPE)
SELECT @x

Beachten Sie, dass die TYPE-Direktive die Abfrageergebnisse als xml-Typ zurückgibt. Wenn die type-Direktive nicht hinzugefügt wird, wird das FOR XML-Abfrageergebnis als nvarchar(max) zurückgegeben. Dieses wird dann in xml umgewandelt und der xml-Typvariablen zugewiesen.

Die FOR XML-Klausel unterliegt den folgenden Einschränkungen:

  • FOR XML ist für SELECT-Anweisungen, die mit einer COMPUTE BY- oder FOR BROWSE-Klausel verwendet werden, nicht gültig. So erzeugt z. B. die folgende Anweisung einen Fehler:

    SELECT TOP 5 SalesOrderID, UnitPrice 
    FROM Sales.SalesOrderDetail 
    ORDER BY SalesOrderID COMPUTE SUM(UnitPrice) BY SalesOrderID
    FOR XML AUTO
    
  • FOR XML der obersten Ebene ohne die TYPE-Direktive kann nicht mit Cursorn verwendet werden.

  • Wenn eine SELECT-Anweisung mit einer FOR XML-Klausel einen vierteiligen Namen in der Abfrage angibt, wird der Servername im sich ergebenden XML-Dokument nicht zurückgegeben, wenn die Abfrage auf dem lokalen Computer ausgeführt wird. Wenn die Abfrage jedoch auf einem Netzwerkserver ausgeführt wird, wird der Servername als vierteiliger Name zurückgegeben.
    Angenommen, Sie haben die folgende Abfrage vorliegen:

    SELECT TOP 1 LastName
    FROM ServerName.AdventureWorks.Person.Contact
    FOR XML AUTO
    

    Wenn ServerName ein lokaler Server ist, gibt die Abfrage Folgendes zurück:

    <AdventureWorks.Person.Contact LastName="Achong" />
    

    Wenn ServerName ein Netzwerkserver ist, gibt die Abfrage Folgendes zurück:

    <ServerName.AdventureWorks.Person.Contact LastName="Achong" />
    

    Diese potenzielle Mehrdeutigkeit kann vermieden werden, indem Sie den folgenden Alias angeben:

    SELECT TOP 1 LastName
    FROM ServerName.AdventureWorks.Person.Contact x
    FOR XML AUTO 
    

    Diese Abfrage gibt Folgendes zurück:

    <x LastName="Achong"/>
    

Darüber hinaus werden SQL Server-Namen, die Zeichen enthalten, die in XML-Namen ungültig sind (wie etwa Leerzeichen), so in XML-Namen übersetzt, dass die ungültigen Zeichen in geschützte numerische Entitätscodierung übersetzt werden.

Nur zwei nicht alphabetische Zeichen können in einem XML-Namen auftreten: der Doppelpunkt (:) und der Unterstrich (_). Da der Doppelpunkt bereits für Namespaces vorbehalten ist, wurde der Unterstrich als Escapezeichen gewählt. Die folgenden Escaperegeln werden für die Codierung verwendet:

  • Alle UCS-2-Zeichen, die keine gültigen Zeichen für XML-Namen gemäß der XML 1.0-Spezifikation sind, werden in _xHHHH_ umgewandelt. HHHH steht für den vierstelligen hexadezimalen UCS-2-Code für das Zeichen in einer nach Signifikanz geordneten Bitfolge. So wird z. B. der Tabellenname Order Details als Order_x0020_Details codiert.

  • Zeichen außerhalb des UCS-2-Bereichs (die UCS-4-Erweiterungen des Bereichs U+00010000 bis U+0010FFFF) werden als _xHHHHHHHH_ codiert. Dabei steht HHHHHHHH für die achtstellige hexadezimale UCS-4-Codierung des Zeichens, wenn der Abwärtskompatibilitätsmodus von SQL Server 2000 verwendet wird. Anderenfalls werden die Zeichen als _xHHHHHH_ codiert, um dem SQL-2003-Standard zu genügen.

  • Das Unterstrichzeichen muss nur dann in ein Escapezeichen umgewandelt werden, wenn das Zeichen x darauf folgt. So wird beispielsweise der Tabellenname Order_Details nicht codiert.

  • Der Doppelpunkt in Bezeichnern wird nicht in eine Escapezeichenfolge umgewandelt. Als Ergebnis können Element- und Attributnamen für Namespaces von der FOR XML-Abfrage generiert werden. So generiert z. B. die folgende Abfrage ein Namespaceattribut mit einem Doppelpunkt im Namen:

    SELECT 'namespace-urn' as 'xmlns:namespace', 
     1 as 'namespace:a' 
    FOR XML RAW
    

    Die Abfrage liefert folgendes Ergebnis:

    <row xmlns:namespace="namespace-urn" namespace:a="1"/>
    

    Beachten Sie, dass WITH XMLNAMESPACES das empfohlene Verfahren zum Hinzufügen von XML-Namespaces ist.

  • In einer SELECT-Abfrage werden Spalten durch Konvertieren in BLOB (Binary Large Object) insofern zu einer temporären Entität, als sie den zugehörigen Tabellen- und Spaltennamen verlieren. Abfragen im AUTO-Modus geben daher einen Fehler aus, da der Wert nicht in der XML-Hierarchie eingeordnet werden kann. Beispiel:

    CREATE TABLE MyTable (Col1 int PRIMARY KEY, Col2 binary)
    INSERT INTO MyTable VALUES (1, 0x7)
    

    Diese Abfrage führt wegen der Konvertierung in BLOB (Binary Large Object) zu einem Fehler:

    SELECT Col1,
    CAST(Col2 as image) as Col2
    FROM MyTable
    FOR XML AUTO
    

    Die Lösung besteht im Hinzufügen der Option BINARY BASE64 zur FOR XML-Klausel. Ohne die Konvertierung liefert die Abfrage die erwarteten Ergebnisse:

    SELECT Col1,
    Col2
    FROM MyTable
    FOR XML AUTO
    

    Folgendes Ergebnis wird ausgegeben:

    <MyTable Col1="1" Col2="dbobject/MyTable[@Col1='1']/@Col2" />
    
  • In SQL Server 2000 kann die FOR XML-Ausgabe ungültige XML-Zeichen enthalten. Der hexadezimale Wert 7 wird z. B. als Formatzeichen verwendet, ansonsten in der Regel jedoch nicht als Text in der Ausgabe angezeigt. SQL Server 2005 ändert solche Zeichen nun in Entitäten, wenn sie in FOR XML-Abfragen zurückgegeben werden, die nicht die TYPE-Direktive verwenden.
    Zwar lösen XML 1.0-konforme Parser Analysefehler unabhängig davon aus, ob diese Zeichen in Entitäten geändert wurden, die Entitätsform ist jedoch kompatibler mit XML 1.1. Die Entitätsform ist außerdem möglicherweise kompatibler mit zukünftigen Versionen des XML-Standards. Darüber hinaus vereinfacht sie das Debuggen, weil das Codeelement des ungültigen Zeichens sichtbar wird.
    Für Benutzer von XML-Tools ist keine Problemumgehung erforderlich, weil der XML-Parser unter allen Umständen an dem Punkt fehlschlägt, an dem das ungültige Zeichen im Datenstrom auftritt. Wenn Sie Nicht-XML-Tools verwenden, kann diese Änderung das Aktualisieren der Programmierlogik erforderlich machen, damit diese nach diesen Zeichen als in Entitäten geänderte Werte sucht.

  • In SQL Server 2005 werden nun die folgenden Leerzeichen in FOR XML-Abfragen auf andere Weise in Entitäten geändert, um ihr Vorhandensein bei Roundtrips zu bewahren:

    • In Elementinhalten und -attributen: hex(0D) (Wagenrücklauf)
    • In Attributinhalten: hex(09) (Tabulator), hex(0A) (Zeilenvorschub)

    Diese Änderung kann Auswirkungen auf Ihre Anwendung besitzen, wenn diese ursprünglich für die Verarbeitung von SQL Server 2000-Ausgaben konzipiert wurde, in denen diese Zeichen normalisiert waren. Die SQL Server 2005-Ausgabe behält diese Zeichen nun bei, und ein Parser normalisiert sie nicht mehr.

Siehe auch

Verweis

Erstellen von XML mithilfe von FOR XML

Andere Ressourcen

SELECT (Transact-SQL)

Hilfe und Informationen

Informationsquellen für SQL Server 2005