У реченні FOR XML можна запросити, щоб запит повертав вбудовану схему разом з результатами запиту. Якщо потрібно отримати XDR-схему, то в реченні FOR XML слід використовувати ключове слово XMLDATA. Якщо потрібно отримати XSD-схему, то тоді слід використовувати ключове слово XMLSCHEMA.
У цьому розділі описується ключове слово XMLSCHEMA і пояснюється структура результуючої вбудованої XSD-схеми. Далі наведені обмеження, що виникають при запиті вбудованих схем.
Параметр XMLSCHEMA можна задати тільки в режимах RAW і AUTO, цього не можна зробити в режимі EXPLICIT.
Якщо у вкладеному запиті FOR XML визначена директива TYPE, результат запиту буде мати тип даних xml і передаватися за екземпляр нетипізований XML-даних. Додаткові відомості див. У розділі XML-дані (SQL Server).
У присутньої в результаті схемою може перебувати безліч документів схеми, що описують різні простору імен. Повертатися повинні, як мінімум, наступні дві схеми.
Один документ схеми для простору імен Sqltypes. для якого повертаються базові типи SQL.
Інший документ схеми, що описує форму результату запиту FOR XML.
Крім того, якщо в результат запиту входять будь-які типізовані типи даних xml. то повертаються схеми, пов'язані з цими типами даних xml.
Цільовий простір імен документа схеми, що описує форму результату FOR XML, містить фіксовану частину і числову частину, яка автоматично збільшується. Далі показаний формат даного простору імен, де n є позитивним цілим числом. Наприклад, в попередньому запиті цільовим простором імен було urn: schemas-microsoft-com: sql: SqlRowSet1.
Зміни в цільових просторах імен в результаті, що стався між двома виконаннями, можуть бути небажані. Наприклад, якщо запитується результуючий XML, то при зміні в цільових просторах імен необхідно оновити запит. При необхідності можна задати цільове простір імен, коли в пропозицію FOR XML доданий параметр XMLSCHEMA. Результуючий XML буде містити вказане простір імен і залишатися незмінним незалежно від того, скільки разів виконували запит.
Через те, що в запит додана директива ELEMENTS, XML-результат формується з використанням елементів. Також в цьому запиті задана директива XMLSCHEMA, тому повертається вбудована XSD-схема. Результуючий набір:
Зверніть увагу на наступні дані з попереднього запиту.
У наступних міркуваннях використовуються таблиці CustOrder і CustOrderDetail. Для перевірки наступних зразків створіть такі ж таблиці і додайте власні зразки даних:
Це отримується в результаті XML. Показана лише частина вбудованої XSD:
Зверніть увагу на наступне у вбудованій XSD-схемі.
Обидва значення, ListPrice і DealerPrice, мають один і той же тип даних, money. і обидва можуть мати в таблиці значення NULL. Таким чином, через те, що вони можуть не повертатися в результуючому XML, в декларації складного типу елемента
В результаті через те, що значення DealerPrice в таблиці одно NULL, як елемент
Випадок 2. Один ключовий стовпець і один неключових стовпець однакового типу
У наступному запиті знаходиться один ключовий стовпець і один неключових стовпець однакового типу.
Результат. Показана лише частина вбудованої XSD-схеми:
Зверніть увагу, що у вбудованій XSD-схемі елемент
Випадок 3. Обидва елементи різних типів і відповідні стовпці можуть мати значення NULL
Для випадку 2 показаний наступний запит, заданий щодо таблиці-зразка:
У цьому запиті Col2 і Col3 мають однакові псевдонімами. Це призводить до появи двох елементів з однаковими іменами, які є дочірніми елементами елемента
IgnoreKanaType IgnoreWidth "sqltypes: sqlSortId =" 52 "> Зверніть увагу на наступне у вбудованій XSD-схемі. В результаті кожен екземпляр елемента