Зміна рівня сумісності в той час, коли користувачі підключені до бази даних, може привести до формування невірних результуючих наборів для активних запитів. Наприклад, якщо рівень сумісності зміниться під час компіляції плану запиту, скомпільований план може грунтуватися на обох, старому і новому, рівнях сумісності, що в результаті дасть невірний план і потенційно неточні результати. Більш того, проблема може стати ще більш заплутаною, якщо план буде поміщений в кеш планів і повторно використаний для подальших запитів. Щоб запити не видавали невірних результатів, рекомендується скористатися такою процедурою для зміни рівня сумісності бази даних.
Перекласти базу даних в одного користувача режим роботи за допомогою інструкції ALTER DATABASE SET SINGLE_USER.
Змінити рівень сумісності бази даних.
Перекласти базу даних в багатокористувацький режим роботи за допомогою інструкції ALTER DATABASE SET MULTI_USER.
Додаткові відомості про встановлення режимів роботи бази даних див. Розділ ALTER DATABASE (Transact-SQL).
При виконанні процедури, що використовується поточний рівень сумісності бази даних, в якій вона була визначена. Коли настройка сумісності бази даних піддається зміні, все збережені процедури цієї бази даних автоматично перекомпілюються відповідним чином.
У цьому розділі описуються нові особливості поведінки, зумовлені появою рівня сумісності 120.
Рівень сумісності 110 і нижче
Установка рівня сумісності 120
Використовується старий оптимізатор запитів.
Якщо рівні сумісності нижче 120, при перетворенні значення date в строкове параметр мови не враховується. Зверніть увагу, що це поведінка специфічно тільки для типу date. Наприклад, наступний запит не враховує інструкцію SET LANGUAGE, за винятком виконання при рівні сумісності 120.
Параметр мови не враховується при перетворенні значення date в строкове.
Рекурсивні посилання в правій частині пропозиції EXCEPT створюють нескінченний цикл. Наступний приклад демонструє цю ситуацію.
При рівні сумісності 110 стиль за замовчуванням для операцій CAST і CONVERT над типами даних time і datetime2 завжди має значення 121. Якщо запит заснований на колишньому поведінці, слід використовувати рівень сумісності нижче 110, або явно задати в зачіпають запиті стиль 0.
Оновлення бази даних до рівня сумісності 110 не приведе до зміни призначених для користувача даних, збережених на диску. Слід виправити ці даних відповідним чином вручну. Наприклад, якби ви використовували пропозицію SELECT INTO для створення таблиці на основі джерела, що містить описане вище вираз обчислюється стовпчика, то зберігалися б дані (завдяки стилю 0), а не саме визначення обчислюваного стовпця. Знадобилося б вручну оновлювати ці дані відповідно до стилю 121.
Будь-які стовпці віддалених таблиць типу smalldatetime. фігурують в Секціонірованние поданні, зіставляються з типом datetime. Відповідні їм стовпці локальних таблиць (стовпці, що займають ті ж порядкові позиції в списку вибору) повинні мати тип datetime.
Будь-які стовпці віддалених таблиць типу smalldatetime. фігурують в Секціонірованние поданні, зіставляються з типом smalldatetime. Відповідні їм стовпці локальних таблиць (стовпці, що займають ті ж порядкові позиції в списку вибору) повинні мати тип smalldatetime.
Після поновлення до рівня сумісності 110 відбудеться збій розподіленого Секціонірованние уявлення через невідповідність типу даних. Дану проблему ви можете вирішити шляхом зміни типу даних у віддаленій таблиці на datetime або задавши рівень сумісності локальної бази даних рівним 100 або нижче.
Функція SOUNDEX реалізує наступні правила.
Символи H і W в верхньому регістрі ігноруються, якщо вони поділяють 2 приголосні, які мають однаковий номер в коді SOUNDEX.
Якщо перші 2 символи character_expression мають однаковий номер в коді SOUNDEX, включаються обидва символи. Інакше, якщо набір послідовних згодних в коді SOUNDEX має той же номер, всі вони виключаються, окрім першого символу.
Функція SOUNDEX реалізує наступні правила.
Якщо букви (у верхньому регістрі) H або W поділяють дві приголосні букви, які мають однаковий номер в коді SOUNDEX, то згодна буква, яка знаходиться праворуч, ігнорується.
Якщо набір послідовних згодних має той же номер в коді SOUNDEX, то всі вони виключаються, окрім першого символу.
Функція SOUNDEX реалізує додаткові правила, при застосуванні яких значення, що обчислюються функцією, можуть відрізнятися від тих значень, які були обчислені при іншому рівні сумісності. Після поновлення до рівня сумісності 110, можливо, доведеться перебудувати індекси, купи або обмеження CHECK, в яких використовується функція SOUNDEX. Додаткові відомості див. У розділі SOUNDEX (Transact-SQL).
До спеціальних атрибутів xsi: nil і xsi: type можна виконувати запити чи вносити в них зміни за допомогою інструкцій DML.
Це означає, що вираз / e / @ xsi: nil закінчується невдачею, незважаючи на те, що в реченні / e / @ * атрибути xsi: nil і xsi: type пропускаються. Однак пропозиція / e повертає атрибути xsi: nil і xsi: type для узгодженості з інструкцією SELECT xmlCol. навіть якщо xsi: nil = "false".
Спеціальні атрибути xsi: nil і xsi: type зберігаються як звичайні атрибути, і до них можна виконувати запити і вносити в них зміни.
Наприклад, виконання запиту SELECT x.query ( 'a / b / @ *') повертає всі атрибути, включаючи xsi: nil і xsi: type. Щоб виключити ці типи з запиту, замініть пропозицію @ * пропозицією @ * [namespace-uri (.)! = "Insert xsi namespace uri" and not (local-name (.) = "Type" or local-name (.) = "nil".
Обумовлена користувачем функція, яка перетворює строкове значення константи XML в тип SQL Server datetime, відзначається як детермінована.
Обумовлена користувачем функція, яка перетворює строкове значення константи XML в тип SQL Server datetime, відзначається як недетермінірованного.
Об'єднання XML і типи списків підтримуються в повному обсязі.
Об'єднання і типи списків підтримуються повністю, включаючи такі функціональні можливості.
Список атомарних типів
Перевірка правильності параметрів SET, необхідних для методу xQuery, не виконується, якщо метод міститься в поданні або у вбудованій повертає табличне значення функції.
Перевірка правильності параметрів SET, необхідних для методу xQuery, виконується, якщо метод міститься в поданні або у вбудованій повертає табличне значення функції. Якщо параметри SET методу задані неправильно, виникає помилка.
Значення XML-атрибута, які містять символи кінця рядка (символи повернення каретки і переведення рядка), що не нормалізовані відповідно до стандарту XML. Таким чином, повертаються обидва символи замість одного символу перекладу рядка.
Значення XML-атрибута, які містять символи кінця рядка (символи повернення каретки і переведення рядка), нормалізовані відповідно до стандарту XML. Таким чином, всі символи кінця рядка в зовнішніх проаналізованих сутності (включаючи сутність документа), нормалізуються на вході, перетворюючи Двосимвольні послідовності #xD #xA і символи #xD, за якими не слід символ #xA, в єдиний символ #xA.
Додатки, в яких використовуються атрибути для перенесення строкових значень, що містять символи кінця рядка, не отримують ці символи назад в тому вигляді, в якому вони були передані. Щоб запобігти виконанню цього процесу нормалізації, використовуйте числові суті-символи XML для кодування всіх символів кінця рядка.
Властивості стовпчика ROWGUIDCOL і IDENTITY можуть бути неправильно іменовані як обмеження. Наприклад, інструкція CREATE TABLE T (C1 int CONSTRAINT MyConstraint IDENTITY) виконується, але ім'я обмеження не зберігається і не є для користувача.
Властивості стовпчика ROWGUIDCOL і IDENTITY не можуть бути іменовані як обмеження. Повертається помилка 156.
Оновлення стовпців з використанням двостороннього привласнення, такого як UPDATE T1 SET @v = column_name =
Така поведінка може бути застосовано, лише якщо рівень сумісності дорівнює 90.
Оновлення стовпців з використанням двостороннього присвоювання призводить до отримання очікуваних результатів, оскільки під час виконання інструкції відбувається доступ тільки до початкового значення стовпця в інструкції.
Присвоєння значення змінної допускається в інструкції, що містить оператор UNION верхнього рівня, але повертає непередбачені результати. Наприклад, в наступних інструкціях локальної змінної @v присвоюється значення стовпця BusinessEntityID з об'єднання двох таблиць. Якщо інструкція SELECT повертає більше одного значення, змінної присвоюється останнім повернене значення. В цьому випадку змінної правильно присвоюється останнє значення, але відбувається також повернення результуючого набору інструкції SELECT UNION.