Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Dotyczy:SQL Server
Azure SQL Database
Azure SQL Managed Instance
Ten temat opisuje ogólne różnice między formatowaniem XML po stronie klienta i serwera w SQLXML.
Wiele zapytań w zestawie wierszy nieobsługiwanych w formatowaniu po stronie klienta
Zapytania generujące wiele zestawów wierszy nie są obsługiwane, gdy używasz formatowania XML po stronie klienta. Na przykład, załóżmy, że masz wirtualny katalog, w którym określono formatowanie po stronie klienta. Rozważmy ten przykładowy szablon, który zawiera dwie instrukcje SELECT w bloku sql:query<>:
<ROOT xmlns:sql="urn:schemas-microsoft-com:xml-sql">
<sql:query>
SELECT FirstName FROM Person.Contact FOR XML Nested;
SELECT LastName FROM Person.Contact FOR XML Nested
</sql:query>
</ROOT>
Możesz uruchomić ten szablon w kodzie aplikacji i pojawi się błąd, ponieważ formatowanie XML po stronie klienta nie obsługuje formatowania wielu zestawów wierszy. Jeśli określisz zapytania w dwóch oddzielnych <blokach sql:query> , uzyskasz pożądane wyniki.
Znaczniki czasowe różnią się w formatowaniu po stronie klienta i serwera
W formatowaniu XML po stronie serwera, kolumna bazy danych typu znacznika czasu odpowiada typowi i8 XDR (gdy opcja XMLDATA jest określona w zapytaniu).
W formatowaniu XML po stronie klienta kolumna bazy danych typu znacznika czasu przypisuje się albo uri , albo typu bin.base64 XDR (w zależności od tego, czy w zapytaniu określono opcję binarną base64). Typ bin.base64 XDR jest przydatny, jeśli korzystasz z funkcji updategram i bulkload, ponieważ ten typ jest konwertowany na typ timestamp SQL Server. W ten sposób operacja wstawienia, aktualizacji lub usunięcia przebiega sukcesem.
Głębokie WARIANTY są stosowane w formatowaniu po stronie serwera
W formatowaniu XML po stronie serwera stosuje się głębokie typy typu VARIANT. Jeśli używasz formatowania XML po stronie klienta, warianty są konwertowane na string Unicode, a podtypy VARIANT nie są używane.
NESTED Mode vs. AUTO Mode
Tryb NESTED FOR XML po stronie klienta jest podobny do trybu AUTO po stronie serwera FOR XML, z następującymi wyjątkami:
Gdy zapytujesz widoki w trybie AUTO po stronie serwera, nazwa widoku jest zwracana jako nazwa elementu w powstałym pliku XML.
Na przykład, załóżmy, że następujący widok jest utworzony w tabeli Person.Contact w bazie AdventureWorks:
CREATE VIEW ContactView AS (SELECT ContactID as CID,
FirstName as FName,
LastName as LName
FROM Person.Contact)
Poniższy szablon określa zapytanie względem widoku ContactView oraz określa formatowanie XML po stronie serwera:
<ROOT xmlns:sql="urn:schemas-microsoft-com:xml-sql">
<sql:query client-side-xml="0">
SELECT *
FROM ContactView
FOR XML AUTO
</sql:query>
</ROOT>
Po wykonaniu szablonu zwracany jest następujący plik XML. (Pokazane są tylko częściowe wyniki.) Należy zauważyć, że nazwy elementów to nazwy widoków, na których wykonywane jest zapytanie.
<ROOT xmlns:sql="urn:schemas-microsoft-com:xml-sql">
<ContactView CID="1" FName="Gustavo" LName="Achong" />
<ContactView CID="2" FName="Catherine" LName="Abel" />
...
</ROOT>
Gdy określasz formatowanie XML po stronie klienta za pomocą odpowiadającego mu trybu NESTED, nazwy tabel bazowych zwracane są jako nazwy elementów w powstałym XML. Na przykład poniższy poprawiony szablon wykonuje to samo zdanie SELECT, ale formatowanie XML jest wykonywane po stronie klienta (czyli szablon jest ustawiony na true):
<ROOT xmlns:sql="urn:schemas-microsoft-com:xml-sql">
<sql:query client-side-xml="1">
SELECT *
FROM ContactView
FOR XML NESTED
</sql:query>
</ROOT>
Wykonanie tego szablonu generuje następujący plik XML. Należy zauważyć, że nazwa elementu jest w tym przypadku nazwą tabeli bazowej.
<ROOT xmlns:sql="urn:schemas-microsoft-com:xml-sql">
<Person.Contact CID="1" FName="Gustavo" LName="Achong" />
<Person.Contact CID="2" FName="Catherine" LName="Abel" />
...
</ROOT>
Gdy używasz trybu AUTO po stronie serwera FOR XML, aliasy tabel określone w zapytaniu są zwracane jako nazwy elementów w powstałym XML.
Na przykład rozważmy ten szablon:
<ROOT xmlns:sql="urn:schemas-microsoft-com:xml-sql">
<sql:query client-side-xml="0">
SELECT FirstName as fname,
LastName as lname
FROM Person.Contact C
FOR XML AUTO
</sql:query>
</ROOT>
Wykonanie szablonu generuje następujący plik XML:
<ROOT xmlns:sql="urn:schemas-microsoft-com:xml-sql">
<C fname="Gustavo" lname="Achong" />
<C fname="Catherine" lname="Abel" />
...
</ROOT>
Gdy używasz trybu NESTED po stronie klienta DLA XML, nazwy tabel są zwracane jako nazwy elementów w powstałym XML. (Aliasy tabel określone w zapytaniu nie są używane.) Na przykład rozważmy ten szablon:
<ROOT xmlns:sql="urn:schemas-microsoft-com:xml-sql">
<sql:query client-side-xml="1">
SELECT FirstName as fname,
LastName as lname
FROM Person.Contact C
FOR XML NESTED
</sql:query>
</ROOT>
Wykonanie szablonu generuje następujący plik XML:
<ROOT xmlns:sql="urn:schemas-microsoft-com:xml-sql">
<Person.Contact fname="Gustavo" lname="Achong" />
<Person.Contact fname="Catherine" lname="Abel" />
...
</ROOT>
Jeśli masz zapytanie, które zwraca kolumny jako zapytania dbobject, nie możesz używać aliasów dla tych kolumn.
Na przykład rozważmy następujący szablon, który wykonuje zapytanie zwracające identyfikator pracownika oraz zdjęcie.
<ROOT xmlns:sql="urn:schemas-microsoft-com:xml-sql">
<sql:query client-side-xml="1">
SELECT ProductPhotoID, LargePhoto as P
FROM Production.ProductPhoto
WHERE ProductPhotoID=5
FOR XML NESTED, elements
</sql:query>
</ROOT>
Wykonanie tego szablonu zwraca kolumnę Photo jako zapytanie dbobject. W tym zapytaniu dbobject odnosi się @P do nazwy kolumny, która nie istnieje.
<ROOT xmlns:sql="urn:schemas-microsoft-com:xml-sql">
<Production.ProductPhoto>
<ProductPhotoID>5</ProductPhotoID>
<LargePhoto>dbobject/Production.ProductPhoto[@ProductPhotoID='5']/@P</LargePhoto>
</Production.ProductPhoto>
</ROOT>
Jeśli formatowanie XML jest wykonywane na serwerze (klient-side-xml="0"), możesz użyć aliasu dla kolumn zwracających zapytania dbobject, w których zwracane są rzeczywiste nazwy tabel i kolumn (nawet jeśli masz określone aliasy). Na przykład następujący szablon wykonuje zapytanie, a formatowanie XML jest wykonywane na serwerze (opcja xml po stronie klienta nie jest określona, a opcja Run On Client nie jest wybrana dla wirtualnego root). Zapytanie określa także tryb AUTO (a nie tryb NESTED po stronie klienta).
<ROOT xmlns:sql="urn:schemas-microsoft-com:xml-sql">
<sql:query
SELECT ProductPhotoID, LargePhoto as P
FROM Production.ProductPhoto
WHERE ProductPhotoID=5
FOR XML AUTO, elements
</sql:query>
</ROOT>
Po wykonaniu tego szablonu zwracany jest następujący dokument XML (należy zauważyć, że aliasy nie są używane w zapytaniu dbobject dla kolumny LargePhoto):
<ROOT xmlns:sql="urn:schemas-microsoft-com:xml-sql">
<Production.ProductPhoto>
<ProductPhotoID>5</ProductPhotoID>
<LargePhoto>dbobject/Production.ProductPhoto[@ProductPhotoID='5']/@LargePhoto</LargePhoto>
</Production.ProductPhoto>
</ROOT>
XPath po stronie klienta vs. serwerowy
XPath po stronie klienta i serwerowy działają tak samo, z wyjątkiem następujących różnic:
Konwersje danych, które są stosowane przy użyciu zapytań XPath po stronie klienta, różnią się od tych, które stosuje się przy zapytaniach XPath po stronie serwera. XPath po stronie klienta używa CAST zamiast trybu CONVERT 126.
Gdy określasz w szablonie stronę klienta-xml="0" (false), prosisz o formatowanie XML po stronie serwera. Dlatego nie można określić DLA XML NESTED, ponieważ serwer nie rozpoznaje opcji NESTED. Spowoduje to wygenerowanie błędu. Musisz używać trybów AUTO, RAW lub EXPLICIT, które serwer rozpoznaje.
Gdy określasz w szablonie stronę klienta-xml="1" (true), prosisz o formatowanie XML po stronie klienta. W takim przypadku możesz określić DLA XML ZAGNIEŻDŻONEGO. Jeśli określisz XML AUTO, formatowanie XML odbywa się po stronie serwera, chociaż szablon określa pliki client-side-xml="1".
Zobacz też
FOR XML Security Considerations (SQLXML 4.0)
Formatowanie XML po stronie klienta (SQLXML 4.0)
Formatowanie XML po stronie serwera (SQLXML 4.0)