Úroveň kompatibility ALTER DATABASE (Transact-SQL)

Platí pro:SQL ServerAzure SQL DatabaseSpravovaná instance Azure SQL

Nastaví Transact-SQL a chování zpracování dotazů tak, aby byly kompatibilní se zadanou verzí modulu SQL. Další možnosti ALTER DATABASE naleznete v tématu ALTER DATABASE.

Další informace o konvencích syntaxe najdete v tématu Transact-SQL konvence syntaxe.

Syntaxe

ALTER DATABASE database_name
SET COMPATIBILITY_LEVEL = { 170 | 160 | 150 | 140 | 130 | 120 | 110 | 100 }

Argumenty

database_name

Název databáze, která se má upravit.

COMPATIBILITY_LEVEL { 170 | 160 | 150 | 140 | 130 | 120 | 110 | 100 | 90 | 80 }

Verze SYSTÉMU SQL Server, se kterou má být databáze kompatibilní. Můžete nakonfigurovat následující hodnoty úrovně kompatibility (ne všechny verze podporují všechny výše uvedené úrovně kompatibility):

Výrobek	Verze databázového stroje	Výchozí označení úrovně kompatibility	Podporované hodnoty úrovně kompatibility
Azure SQL Database	17	170	170, 160, 150, 140, 130, 120, 110, 100
Řízená instance Azure SQL	16	sto padesát	160, 150, 140, 130, 120, 110, 100
SQL Server 2025 (17.x) Preview	17	170	170, 160, 150, 140, 130, 120, 110, 100
SQL Server 2022 (16.x)	16	160	160, 150, 140, 130, 120, 110, 100
SQL Server 2019 (15.x)	15	sto padesát	150, 140, 130, 120, 110, 100
SQL Server 2017 (14.x)	14	140	140, 130, 120, 110, 100
SQL Server 2016 (13.x)	13	130	130, 120, 110, 100
SQL Server 2014 (12.x)	12	120	120, 110, 100
SQL Server 2012 (11.x)	11	110	110, 100, 90
SQL Server 2008 R2 (10.50.x)	10.5	100	100, 90, 80
SQL Server 2008 (10.0.x)	10	100	100, 90, 80
SQL Server 2005 (9.x)	9	90	90, 80
SQL Server 2000 (8.x)	8	80	80

Důležité

Čísla verzí databázového stroje pro SQL Server a Azure SQL Database nejsou vzájemně srovnatelná a jsou spíše interními čísly buildů pro tyto samostatné produkty. Databázový stroj pro Azure SQL Database je založený na stejném základu kódu jako databázový stroj SQL Serveru. Nejdůležitější je, že databázový stroj ve službě Azure SQL Database má vždy nejnovější bity databázového stroje SQL. Verze 12 služby Azure SQL Database je novější než verze 15 SQL Serveru.

Osvědčené postupy pro upgrade úrovně kompatibility databáze

Doporučený pracovní postup pro upgrade úrovně kompatibility najdete v tématu Zachování stability výkonu během upgradu na novější SQL Server. Další informace o asistovaném prostředí s upgradem úrovně kompatibility databáze najdete v tématu Upgrade databází pomocí Pomocníka pro ladění dotazů.

Poznámky

Pro všechny instalace SQL Serveru je výchozí úroveň kompatibility přidružena k verzi databázového stroje. Nové databáze jsou nastaveny na tuto úroveň, pokud model databáze nemá nižší úroveň kompatibility. U databází připojených nebo obnovených z jakékoli starší verze SQL Serveru zachová databáze stávající úroveň kompatibility, pokud je pro danou instanci SQL Serveru alespoň povolená. Přesunutí databáze s nižší než povolenou úrovní kompatibility databázovým strojem automaticky nastaví databázi na nejnižší povolenou úroveň kompatibility. To platí pro systémové i uživatelské databáze.

U SQL Serveru 2017 (14.x) se očekává následující chování při připojení nebo obnovení databáze a po místní upgradu:

• Pokud byla úroveň kompatibility uživatelské databáze před upgradem 100 nebo vyšší, zůstane po upgradu stejná.
• Pokud byla úroveň kompatibility uživatelské databáze před upgradem 90, v upgradované databázi je úroveň kompatibility nastavena na 100, což je nejnižší podporovaná úroveň kompatibility v SQL Serveru 2017 (14.x).
• Úrovně tempdbkompatibility databází , , modelmsdba prostředků jsou nastaveny na výchozí úroveň kompatibility pro danou verzi databázového stroje.
• master Systémová databáze uchovává úroveň kompatibility, kterou měla před upgradem. Nebude to mít vliv na chování uživatelské databáze.

U existujících databází běžících na nižších úrovních kompatibility platí, že pokud aplikace nepotřebuje používat vylepšení, která jsou k dispozici pouze na vyšší úrovni kompatibility databáze, je platným přístupem k zachování předchozí úrovně kompatibility databáze. Pro novou vývojovou práci nebo v případě, že existující aplikace vyžaduje použití nových funkcí, jako je inteligentní zpracování dotazů v databázích SQL a některé nové transact-SQL, naplánujte upgrade úrovně kompatibility databáze na nejnovější dostupnou úroveň. Další informace najdete v tématu Úrovně kompatibility a upgrady databázového stroje.

Poznámka:

Pokud neexistují žádné uživatelské objekty a závislosti, je obecně bezpečné upgradovat na výchozí úroveň kompatibility. Další informace naleznete v tématu Doporučení – hlavní databáze.

Slouží ALTER DATABASE ke změně úrovně kompatibility databáze. Nové nastavení úrovně kompatibility pro databázi se projeví při USE <database> vydání příkazu nebo se v této databázi zpracuje nové přihlášení jako výchozí kontext databáze.

Pokud chcete zobrazit aktuální úroveň kompatibility databáze, zadejte dotaz na compatibility_level sloupec v zobrazení katalogu sys.databases .

Distribuční databáze vytvořená ve starší verzi SQL Serveru a upgraduje se na SQL Server 2016 (13.x) RTM nebo Service Pack 1, má úroveň kompatibility 90, která není podporovaná pro jiné databáze. To nemá vliv na funkčnost replikace. Upgrade na novější aktualizace Service Pack a verze SQL Serveru způsobí zvýšení úrovně kompatibility distribuční databáze tak, aby odpovídala master úrovni databáze.

Pokud chcete pro databázi použít úroveň kompatibility databáze 120 nebo vyšší, ale přihlaste se k modelu odhadu kardinality SYSTÉMU SQL Server 2012 (11.x), který se mapuje na úroveň kompatibility databáze 110, přečtěte si téma ALTER DATABASE SCOPED CONFIGURATION a zejména jeho klíčové slovo LEGACY_CARDINALITY_ESTIMATION = ON.

Poznámky pro Azure SQL

Výchozí úroveň kompatibility je 170 pro nově vytvořené databáze v Azure SQL Database a databázi SQL v Microsoft Fabric.

Výchozí úroveň kompatibility je 150 pro nově vytvořené databáze v zásadách aktualizace SQL Serveru 2022 nabídky Azure SQL Managed Instance.

Výchozí úroveň kompatibility je 170 pro nově vytvořené databáze v zásadách aktualizace always-up-to-date nabídky Azure SQL Managed Instance.

Microsoft automaticky neaktualizuje úroveň kompatibility databáze pro stávající databáze. Je na zákaznících, aby to udělali podle vlastního uvážení.

Microsoft důrazně doporučuje, aby zákazníci plánovali upgrade na nejnovější úroveň kompatibility, aby mohli používat nejnovější vylepšení optimalizace dotazů. Tipy k posouzení rozdílů mezi výkonem nejdůležitějších dotazů mezi dvěma různými úrovněmi kompatibility ve službě Azure SQL Database najdete v tématu Vylepšení výkonu dotazů s úrovní kompatibility 130 ve službě Azure SQL Database. Tento článek se týká úrovně kompatibility 130 a SQL Serveru, ale stejná metodologie platí pro upgrady na 140 nebo vyšší úrovně v SQL Serveru a Azure SQL Database.

Azure SQL Database nepodporuje všechny funkce, které se liší podle úrovně kompatibility.

Vyhledání aktuální úrovně kompatibility

Pokud chcete zjistit aktuální úroveň kompatibility, zadejte dotaz na compatibility_level sloupec sys.databases.

SELECT [name],
       compatibility_level
FROM sys.databases;

Pokud chcete zjistit verzi databázového stroje, ke kterému jste připojení, spusťte následující dotaz.

SELECT SERVERPROPERTY('ProductVersion');

Úrovně kompatibility a upgrady databázového stroje

Úroveň kompatibility databáze je cenný nástroj, který pomáhá s modernizací databáze tím, že umožňuje upgrade databázového stroje SQL Serveru a zachování stejného funkčního stavu pro připojení aplikací zachováním stejné úrovně kompatibility databáze před upgradem. To znamená, že je možné upgradovat ze starší verze SQL Serveru (například SQL Serveru 2008 (10.0.x)) na SQL Server nebo Azure SQL Database (včetně služby Azure SQL Managed Instance) beze změn aplikace (s výjimkou připojení k databázi). Další informace najdete v tématu Certifikace kompatibility.

Pokud aplikace nepotřebuje používat vylepšení, která jsou k dispozici pouze na vyšší úrovni kompatibility databáze, jedná se o platný přístup k upgradu databázového stroje SQL Serveru a zachování předchozí úrovně kompatibility databáze. Další informace o použití úrovně kompatibility pro zpětnou kompatibilitu naleznete v tématu Certifikace kompatibility.

Úrovně kompatibility a uložené procedury

Když se uložená procedura spustí, použije aktuální úroveň kompatibility databáze, ve které je definovaná. Když se změní nastavení kompatibility databáze, všechny uložené procedury se odpovídajícím způsobem automaticky znovu kompilují.

Použití úrovně kompatibility pro zpětnou kompatibilitu

Nastavení úrovně kompatibility databáze poskytuje zpětnou kompatibilitu se staršími verzemi SQL Serveru v souvislosti s Transact-SQL a chováním optimalizace dotazů pouze pro zadanou databázi, ne pro celý server.

Od režimu kompatibility 130 byly všechny nové plány dotazů ovlivňující opravy a funkce záměrně přidány pouze na novou úroveň kompatibility. To bylo provedeno, aby se minimalizovalo riziko během upgradů, které vznikají z důvodu snížení výkonu kvůli změnám plánu dotazů, které potenciálně zavedly nové chování optimalizace dotazů.

Z hlediska aplikace použijte nižší úroveň kompatibility jako bezpečnější cestu migrace k řešení rozdílů ve verzích v chování, která jsou řízena příslušným nastavením úrovně kompatibility. Cílem by stále mělo být upgrade na nejnovější úroveň kompatibility v určitém okamžiku, aby se zdědily některé nové funkce, jako je inteligentní zpracování dotazů v databázích SQL, ale aby to bylo možné provést řízeným způsobem.

Další informace, včetně doporučeného pracovního postupu pro upgrade úrovně kompatibility databáze, najdete v tématu Osvědčené postupy pro upgrade úrovně kompatibility databáze.

• Ukončené funkce zavedené v dané verzi SQL Serveru nejsou chráněny úrovní kompatibility. To se týká funkcí, které byly odebrány z databázového stroje SQL Serveru. Například FASTFIRSTROW byl tip ukončen v SQL Serveru 2012 (11.x) a nahrazen nápovědou OPTION (FAST n ) . Nastavení úrovně kompatibility databáze na 110 neobnoví ukončenou nápovědu. Další informace o ukončených funkcích naleznete v tématu Ukončené funkce databázového stroje v SYSTÉMU SQL Server.

• Zásadní změny zavedené v dané verzi SQL Serveru nemusí být chráněné úrovní kompatibility. To se týká změn chování mezi verzemi databázového stroje SQL Serveru. Transact-SQL chování je obvykle chráněno úrovní kompatibility. Změněné nebo odebrané systémové objekty však nejsou chráněny úrovní kompatibility.

  Příkladem zásadní změny chráněné úrovní kompatibility je implicitní převod datových typů datetime na datetime2 . V rámci úrovně kompatibility databáze 130 ukazují tyto hodnoty vyšší přesnost tím, že se započítávání desetinných milisekund, což vede k různým převedeným hodnotám. Pokud chcete obnovit předchozí chování převodu, nastavte úroveň kompatibility databáze na 120 nebo nižší.

  Mezi příklady zásadních změn , které nejsou chráněné úrovní kompatibility, patří:

  • Změna názvů sloupců v systémových objektech V SQL Serveru 2012 (11.x) byl sloupec single_pages_kb přejmenován sys.dm_os_sys_info na pages_kb. Bez SELECT single_pages_kb FROM sys.dm_os_sys_info ohledu na úroveň kompatibility dotaz způsobí chybu 207 (Neplatný název sloupce).

  • Odebrané systémové objekty. V SQL Serveru 2012 (11.x) sp_dboption byl odebrán. Bez ohledu na úroveň kompatibility příkaz EXEC sp_dboption 'AdventureWorks2022', 'autoshrink', 'FALSE'; způsobí chybu 2812 (Could not find stored procedure 'sp_dboption').

    Další informace o zásadních změnách najdete tady:

    • Zásadní změny funkcí databázového stroje v SQL Serveru 2019
    • Zásadní změny funkcí databázového stroje v SQL Serveru 2017
    • Zásadní změny funkcí databázového stroje v SQL Serveru 2016

Rozdíly mezi úrovněmi kompatibility

Pro všechny instalace SQL Serveru je výchozí úroveň kompatibility přidružená k verzi databázového stroje, jak je vidět v této tabulce. V případě nové vývojové práce vždy naplánujte certifikaci aplikací na nejnovější úrovni kompatibility databáze.

Nová syntaxe Transact-SQL není brána na úrovni kompatibility databáze, s výjimkou případů, kdy můžou přerušit stávající aplikace vytvořením konfliktu s uživatelským Transact-SQL kódem. Tyto výjimky jsou popsané v dalších částech tohoto článku, které popisují rozdíly mezi konkrétními úrovněmi kompatibility.

Úroveň kompatibility databáze také poskytuje zpětnou kompatibilitu se staršími verzemi SQL Serveru, protože databáze připojené nebo obnovené z jakékoli starší verze SQL Serveru si zachovají stávající úroveň kompatibility (pokud je stejná nebo vyšší než minimální povolená úroveň kompatibility). Tato část byla popsána v části Použití kompatibility pro zpětnou kompatibilitu tohoto článku.

Počínaje úrovní kompatibility databáze 130 byly všechny nové opravy a funkce ovlivňující plány dotazů přidány pouze k nejnovější dostupné úrovni kompatibility, označované také jako výchozí úroveň kompatibility. To bylo provedeno tak, aby se minimalizovalo riziko během upgradů, které vznikají z důvodu snížení výkonu kvůli změnám plánu dotazů, potenciálně zavedených novými chováními optimalizace dotazů.

Základní plán ovlivňující změny přidané pouze do výchozí úrovně kompatibility nové verze databázového stroje jsou:

1. Opravy optimalizátoru dotazů vydané pro předchozí verze SQL Serveru v příznaku trasování 4199 se automaticky povolí ve výchozí úrovni kompatibility novější verze SQL Serveru.

   Platí pro: SQL Server (počínaje verzí SQL Serveru 2016 (13.x)), Azure SQL Database

   Například když byl vydán SQL Server 2016 (13.x), všechny opravy Optimalizátoru dotazů vydané pro předchozí verze SQL Serveru (a odpovídající úrovně kompatibility 100 až 120) se automaticky povolily pro databáze, které používají výchozí úroveň kompatibility SQL Serveru 2016 (13.x). Explicitně je potřeba povolit pouze opravy optimalizátoru dotazů po RTM.

   Pokud chcete povolit opravy optimalizátoru dotazů, můžete použít následující metody:

   • Na úrovni serveru s příznakem trasování 4199.
   • Na úrovni databáze s QUERY_OPTIMIZER_HOTFIXES možností ALTER DATABASE SCOPED CONFIGURATION (Transact-SQL).
   • Na úrovni dotazu můžete pomocí USE HINT 'ENABLE_QUERY_OPTIMIZER_HOTFIXES' dotazu upravit dotaz.
   • Na úrovni dotazu s USE HINT 'ENABLE_QUERY_OPTIMIZER_HOTFIXES' beze změn kódu pomocí funkce nápovědy úložiště dotazů .

   Po vydání SQL Serveru 2017 (14.x) byly vydány všechny opravy optimalizátoru dotazů vydané po vydání SQL Serveru 2016 (13.x) RTM automaticky pro databáze pomocí výchozí úrovně kompatibility SQL Serveru 2017 (14.x). Toto je kumulativní chování, které zahrnuje také všechny opravy předchozích verzí. Znovu je potřeba explicitně povolit pouze opravy optimalizátoru dotazů po RTM.

   Následující tabulka shrnuje toto chování:

   Verze databázového stroje (DE)	Úroveň kompatibility databáze	TF 4199	Změny QO ze všech předchozích úrovní kompatibility databáze	Změny QO pro (DE) verze post-RTM
   13 (SQL Server 2016 (13.x))	100 až 120 130	Vypnuto Na Vypnuto Na	Invalidní Povoleno Zpřístupněný Povoleno	Invalidní Povoleno Invalidní Povoleno
   14 (SQL Server 2017 (14.x))	100 až 120 130 140	Vypnuto Na Vypnuto Na Vypnuto Na	Invalidní Povoleno Zpřístupněný Povoleno Zpřístupněný Povoleno	Invalidní Povoleno Invalidní Povoleno Invalidní Povoleno
   15 (SQL Server 2019 (15.x)) a (Azure SQL Database)	100 až 120 130 až 140 sto padesát	Vypnuto Na Vypnuto Na Vypnuto Na	Invalidní Povoleno Zpřístupněný Povoleno Zpřístupněný Povoleno	Invalidní Povoleno Invalidní Povoleno Invalidní Povoleno
   16 (SQL Server 2022 (16.x)) a (Azure SQL Database)	100 až 120 130 až 150 160	Vypnuto Na Vypnuto Na Vypnuto Na	Invalidní Povoleno Zpřístupněný Povoleno Zpřístupněný Povoleno	Invalidní Povoleno Invalidní Povoleno Invalidní Povoleno
   17 (SQL Server 2025 (17.x) Preview, Azure SQL Database a databáze SQL v Microsoft Fabric)	100 až 120 130 až 160 170	Vypnuto Na Vypnuto Na Vypnuto Na	Invalidní Povoleno Zpřístupněný Povoleno Zpřístupněný Povoleno	Invalidní Povoleno Invalidní Povoleno Invalidní Povoleno

   Opravy optimalizátoru dotazů, které řeší nesprávné výsledky nebo chyby porušení přístupu, nejsou chráněné příznakem trasování 4199. Tyto opravy se nepovažují za volitelné.

2. Změny estimátoru kardinality vydaného na SQL Serveru, Azure SQL Database a databázi SQL v Microsoft Fabric jsou povoleny pouze ve výchozí úrovni kompatibility nové verze databázového stroje, ale ne na předchozích úrovních kompatibility.

   Například při vydání SQL Serveru 2016 (13.x) byly změny v procesu odhadu kardinality k dispozici pouze pro databáze používající SQL Server 2016 (13.x) výchozí úroveň kompatibility (130). Předchozí úrovně kompatibility zachovaly chování odhadu kardinality, které bylo k dispozici před SQL Serverem 2016 (13.x).

   Později, když byl vydán SQL Server 2017 (14.x), byly novější změny odhadu kardinality k dispozici pouze pro databáze používající SQL Server 2017 (14.x) výchozí úroveň kompatibility (140). Úroveň kompatibility databáze 130 zachovala chování odhadu kardinality SQL Serveru 2016 (13.x).

   Následující tabulka shrnuje toto chování:

   Verze databázového stroje	Úroveň kompatibility databáze	Změny nové verze CE
   13 (SQL Server 2016 (13.x))	< 130 130	Invalidní Povoleno
   14 (SQL Server 2017 (14.x))1	< 140 140	Invalidní Povoleno
   15 (SQL Server 2019 (15.x))1	< 150 sto padesát	Invalidní Povoleno
   16 (SQL Server 2022 (16.x))1	< 160 160	Invalidní Povoleno
   17 (SQL Server 2025 (17.x) Preview)1	< 170 170	Invalidní Povoleno

   ¹ Platí také pro Azure SQL Database a databázi SQL v Microsoft Fabric.

Další rozdíly mezi konkrétními úrovněmi kompatibility jsou k dispozici v dalších částech tohoto článku.

Rozdíly mezi úrovní kompatibility 160 a úrovní 170

Tato část popisuje nové chování zavedené s úrovní kompatibility 170.

Nastavení úrovně kompatibility 160 nebo nižší	Nastavení úrovně kompatibility 170
Pokud chcete chránit materiál klíče symetrického klíče, hlavního klíče databáze a hlavního klíče služby, SQL Server a Azure SQL uloží materiál klíče v šifrované podobě. Šifrování používá režim odsazení PKCS#1 v1.5.	Pokud chcete chránit materiál klíče symetrického klíče, hlavního klíče databáze a hlavního klíče služby, SQL Server a Azure SQL uloží materiál klíče v šifrované podobě. Šifrování používá režim odsazení OAEP-256. V dm_database_encryption_keys se CERTIFICATE_OAEP_256CERTIFICATEencryptor_type místo .
Regulární výrazy lze použít ke shodě složitých vzorů a manipulaci s daty v SQL Serveru a databázi Azure SQL. Byla přidána podpora regulárních výrazů v rámci T-SQL. Některé funkce regulárních výrazů nejsou dostupné ve všech úrovních kompatibility databáze. Další informace najdete v tématu Funkce regulárních výrazů.	Funkce regulárních výrazů, jako jsou REGEXP_LIKE, REGEXP_MATCHES a REGEXP_SPLIT_TO_TABLE, byly zavedeny, aby bylo možné přímo v T-SQL povolit porovnávání vzorů, extrakci a rozdělení.
Byla přidána možnost vytvářet vkládání AI (vektorová pole) z textových výrazů. Další informace najdete v tématu Funkce AI.	Představuje funkci AI_GENERATE_CHUNKS, která umožňuje vytváření bloků textových vstupů pro spotřebu modelů AI, což zlepšuje integraci se službami AI.
Databázový stroj tradičně chrání příkazy DML před problémem Halloween zavedením operátoru zařazování do plánu dotazu nebo použitím jiného blokujícího operátoru, který už v plánu existuje, například řazení nebo porovnávání hodnot hash.	Optimalizovaná ochrana Halloween odstraňuje nepotřebné operátory zařazování a zlepšuje výkon dotazů během operací DML, kde je vyžadována ochrana Halloween.
Parametrizované dotazy můžou mít více plánů dotazů uložených v mezipaměti pro různé kategorie selektivity parametru. Optimalizace plánu citlivého na parametry je ve výchozím nastavení povolená v úrovni kompatibility 160 pouze u vybraných dotazů.	Pokud optimalizace plánu citlivého na parametry funguje na úrovni kompatibility 170, je k dispozici také podpora dotazů DML a podpora pro tempdb
Parametrizované dotazy, které mají volitelné parametry, můžou mít neoptimální plány kvůli zašifrování parametrů.	Optimalizace plánu dotazů pro volitelné parametry, což zlepšuje výkon generováním vhodnějších plánů pro hodnoty NULL a nenulové.

Rozdíly mezi úrovní kompatibility 150 a úrovní 160

Tato část popisuje nové chování zavedené s úrovní kompatibility 160.

Nastavení úrovně kompatibility 150 nebo nižší	Nastavení úrovně kompatibility 160
Parametrizované dotazy mají jeden plán dotazu založený na parametrech použitých při prvním spuštění. Do mezipaměti je uložen pouze jeden plán dotazu, který se používá pro všechny hodnoty parametrů. To může způsobit neefektivní plán dotazu pro některé hodnoty parametru, označovaný také jako plán citlivý na parametry.	Parametrizované dotazy můžou mít více plánů dotazů uložených v mezipaměti pro různé kategorie selektivity parametru. Optimalizace plánu citlivého na parametry je ve výchozím nastavení povolená na úrovni kompatibility 160. Další informace naleznete v tématu Optimalizace PSP.
Odhad kardinality používá pouze jednu výchozí sadu předpokladů modelu pro základní distribuci dat a vzory použití pro všechny databáze a dotazy. Jediný způsob, jak některou z těchto předpokladů změnit nebo upravit, je, když uživatel provede ruční proces, který explicitně určí, které předpoklady modelu se mají použít, pomocí nápovědy dotazu. Po vygenerování plánu dotazu není možné u tohoto výchozího modelu provést žádnou vnitřní úpravu.	Odhad kardinality začíná výchozí sadou předpokladů modelu pro základní distribuci dat a vzory použití, ale po některých spuštěních pro daný dotaz se databázový stroj dozví, které různé sady předpokladů modelu můžou přinést přesnější odhady, a proto upraví předpoklady, které se používají, aby lépe odpovídaly dotazované datové sadě. Zpětná vazba CE je ve výchozím nastavení povolená na úrovni kompatibility 160. Další informace naleznete v tématu odhad kardinality (CE) zpětná vazba.
Databázový stroj nepokoušá automatické určení optimálního stupně paralelismu. Informace o ručním řízení maximálního stupně paralelismu (MAXDOP) v instanci, databázi, dotazu nebo úrovních úloh najdete v tématu Konfigurace serveru: maximální stupeň paralelismu.	Stupeň paralelismu (DOP) Zpětná vazba zlepšuje výkon dotazů tím, že identifikuje nevýkonnost paralelismu pro opakující se dotazy na základě uplynulého času a čekání. Pokud je využití paralelismu považováno za neefektivní, sníží zpětná vazba DOP pro další spuštění dotazu, ať už je nakonfigurovaný DOP, a ověří, jestli to pomůže. Zpětná vazba DOP není ve výchozím nastavení povolená. Pokud chcete povolit zpětnou vazbu DOP, povolte DOP_FEEDBACK v databázi konfiguraci s vymezeným oborem databáze. Další informace najdete v tématu Stupeň paralelismu (DOP) zpětná vazba.

Rozdíly mezi úrovní kompatibility 140 a úrovní 150

Tato část popisuje nové chování zavedené s úrovní kompatibility 150.

Nastavení úrovně kompatibility 140 nebo nižší	Nastavení úrovně kompatibility 150
Relační datové sklady a analytické úlohy nemusí být schopné používat indexy columnstore kvůli režii OLTP, nedostatku podpory dodavatelů nebo jiným omezením. Bez indexů columnstore tyto úlohy nemohou těžit z režimu dávkového spouštění.	Režim dávkového spouštění je nyní k dispozici pro analytické úlohy bez nutnosti indexů columnstore. Další informace najdete v dávkovém režimu v úložišti řádků.
Dotazy v režimu řádků, které požadují nedostatečné velikosti přidělení paměti, které vedou k přelití na disk, můžou i nadále mít problémy při po sobě jdoucích spuštěních.	Dotazy v režimu řádků, které požadují nedostatečné velikosti přidělení paměti, které vedou k přelití na disk, můžou mít lepší výkon při po sobě jdoucích spuštěních. Další informace najdete v tématu o udělení zpětné vazby v režimu řádků.
Dotazy v režimu řádků, které požadují nadměrnou velikost grantu paměti, které mají za následek problémy s souběžností, můžou i nadále mít problémy při po sobě jdoucích spuštěních.	Dotazy v režimu řádků, které požadují nadměrnou velikost přidělení paměti, což vede k problémům s souběžností, můžou mít lepší souběžnost při po sobě jdoucích spuštěních. Další informace najdete v tématu o udělení zpětné vazby v režimu řádků.
Dotazy odkazující na skalární uživatele T-SQL budou používat iterativní vyvolání, nedostatek nákladů a vynucení sériového spuštění.	Skalární uživatelem definované uživatelem T-SQL se transformují na ekvivalentní relační výrazy, které jsou "vloženy" do volajícího dotazu, což často vede k významným nárůstům výkonu. Další informace najdete v tématu Inlining skalárního UDF T-SQL.
Proměnné tabulky používají pevný odhad pro odhad kardinality. Pokud je skutečný počet řádků mnohem vyšší než uhodnutá hodnota, může dojít k snížení výkonu podřízených operací.	Nové plány budou místo pevného odhadu používat skutečnou kardinalitu proměnné tabulky, ke které došlo při první kompilaci. Další informace naleznete v tabulkové proměnné odložené kompilace.

Další informace o funkcích zpracování dotazů povolených v úrovni kompatibility databáze 150 najdete v tématu Co je nového v SQL Serveru 2019 a inteligentním zpracování dotazů v databázích SQL.

Rozdíly mezi úrovní kompatibility 130 a úrovní 140

Tato část popisuje nové chování zavedené s úrovní kompatibility 140.

Nastavení úrovně kompatibility 130 nebo nižší	Nastavení úrovně kompatibility 140
Odhady kardinality pro příkazy odkazující na funkce tabulek s více příkazy používají pevný odhad řádku.	Odhady kardinality pro způsobilé příkazy odkazující na funkce s hodnotou tabulky s více příkazy budou používat skutečnou kardinalitu výstupu funkce. To je povoleno prostřednictvím prokládání provádění pro funkce tabulek s více příkazy.
Dotazy v režimu batch, které požadují nedostatečné velikosti přidělení paměti, které vedou k přelití na disk, můžou i nadále mít problémy při po sobě jdoucích spuštěních.	Dotazy v dávkovém režimu, které požadují nedostatečné velikosti přidělení paměti, které vedou k přelití na disk, můžou mít lepší výkon při po sobě jdoucích spuštěních. Tato možnost je povolena prostřednictvím zpětné vazby o udělení paměti v režimu dávky , která aktualizuje velikost přidělení paměti plánu uloženého v mezipaměti, pokud došlo k přelití pro operátory dávkového režimu.
Dotazy v dávkovém režimu, které požadují nadměrnou velikost přidělení paměti, které mají za následek problémy s souběžností, můžou i nadále mít problémy při po sobě jdoucích spuštěních.	Dotazy v dávkovém režimu, které požadují nadměrnou velikost grantu paměti, což vede k problémům souběžnosti, můžou mít lepší souběžnost při po sobě jdoucích spuštěních. Tato možnost je povolena prostřednictvím zpětné vazby k udělení paměti v dávkovém režimu , která aktualizuje velikost přidělení paměti plánu uloženého v mezipaměti, pokud bylo původně požadováno nadměrné množství.
Dotazy v dávkovém režimu, které obsahují operátory spojení, mají nárok na tři algoritmy fyzického spojení, včetně vnořené smyčky, spojení hash a sloučení spojení. Pokud jsou odhady kardinality pro vstupy spojení nesprávné, může být vybrán nevhodný algoritmus spojení. Pokud k tomu dojde, výkon bude trpět a algoritmus nevhodného spojení zůstane používán, dokud se plán v mezipaměti znovu nekompiluje.	Existuje další operátor spojení s názvem adaptivní spojení. Pokud jsou odhady kardinality pro vstup vnějšího spojení sestavení nesprávné, může být vybrán nevhodný algoritmus spojení. Pokud k tomu dojde a příkaz má nárok na adaptivní spojení, použije se pro menší vstupy spojení vnořená smyčka a pro větší vstupy spojení se použije spojení hash dynamicky bez nutnosti rekompilace.
Triviální plány odkazující na indexy Columnstore nemají nárok na provádění dávkového režimu.	Triviální plán odkazující na indexy Columnstore se zahodí ve prospěch plánu, který má nárok na provádění dávkového režimu.
Operátor sp_execute_external_script UDX lze spustit pouze v režimu řádku.	Operátor sp_execute_external_script UDX má nárok na provádění dávkového režimu.
Multi-statement table-valued functions (TVF) nemají prokládání provádění	Prokládání provádění pro multi-statement TVF ke zlepšení kvality plánu.

Opravy, které byly pod příznakem trasování 4199 ve starších verzích SQL Serveru před SQL Serverem 2017, jsou teď ve výchozím nastavení povolené. S režimem kompatibility 140. Příznak trasování 4199 bude stále použitelný pro nové opravy optimalizátoru dotazů vydané po SQL Serveru 2017. Informace o příznaku trasování 4199 naleznete v tématu Příznak trasování 4199.

Rozdíly mezi úrovní kompatibility 120 a úrovní 130

Tato část popisuje nové chování zavedené s úrovní kompatibility 130.

Nastavení úrovně kompatibility 120 nebo nižší	Nastavení úrovně kompatibility 130
INSERT v příkazu INSERT-SELECT je jednovláknové.	Příkaz INSERT v INSERT-SELECT je vícevláknový nebo může mít paralelní plán.
Dotazy na tabulku optimalizovanou pro paměť spouštějí jednovláknové operace.	Dotazy na tabulku optimalizované pro paměť teď můžou mít paralelní plány.
Zavedli jsme nástroj pro posouzení kardinality SQL 2014. CardinalityEstimationModelVersion="120"	Další vylepšení odhadu kardinality (CE) s modelem odhadu kardinality 130, který je viditelný z plánu dotazu. KardinalitaEstimationModelVersion="130"
Dávkový režim versus změny režimu řádků s indexy Columnstore: Řazení v tabulce s indexem Columnstore je v režimu řádků. Agregace funkcí oken fungují v režimu řádků, jako LAG je nebo LEAD Dotazy na tabulky Columnstore s několika různými klauzulemi provozovanými v režimu řádků Dotazy spuštěné v režimu MAXDOP 1 nebo se sériovým plánem spuštěným v režimu řádků	Dávkový režim versus změny režimu řádků s indexy Columnstore: Řazení v tabulce s indexem Columnstore je teď v dávkovém režimu. Agregace oken teď fungují v dávkovém režimu, například LAGLEAD Dotazy na tabulky Columnstore s několika různými klauzulemi pracují v režimu Batch. Dotazy spuštěné v rámci MAXDOP 1 nebo se sériovým plánem spouštěným v režimu Batch
Statistiky je možné aktualizovat automaticky.	Logika, která automaticky aktualizuje statistiky, je u velkých tabulek agresivnější. V praxi by to mělo snížit případy, kdy zákazníci zaznamenali problémy s výkonem u dotazů, kde se nově vložené řádky často dotazují, ale kde se statistiky neaktualizovaly tak, aby tyto hodnoty zahrnovaly.
Trasování 2371 je ve výchozím nastavení v SQL Serveru 2014 (12.x) vypnuté.	Trasování 2371 je ve výchozím nastavení zapnuté v SQL Serveru 2016 (13.x). Příznak trasování 2371 říká aktualizátoru automatických statistik, aby v tabulce, která obsahuje velký počet řádků, vzorkoval menší, ale moudřejší podmnožinu řádků. Jedním z vylepšení je zahrnout do vzorku více řádků, které byly vloženy nedávno. Dalším vylepšením je nechat dotazy běžet, když je spuštěn proces statistik aktualizace, a neblokuje dotaz.
U úrovně 120 se statistiky vzorkují jedním vláknem.	Pro úroveň 130 se statistiky vzorkují vícevláknovým procesem (paralelní proces).
Limit je 253 příchozích cizích klíčů.	Na danou tabulku může odkazovat až 10 000 příchozích cizích klíčů nebo podobných odkazů. Omezení najdete v tématu Vytváření relací cizích klíčů.
Zastaralé hashovací algoritmy MD2, MD4, MD5, SHA a SHA1 jsou povolené.	Jsou povoleny pouze SHA2_256 a SHA2_512 hashovací algoritmy.
	SQL Server 2016 (13.x) zahrnuje vylepšení některých převodů datových typů a některých (většinou neobvyklých) operací. Podrobnosti najdete v tématu Vylepšení SQL Serveru a Azure SQL Database při zpracování některých datových typů a neobvyklých operací.
Funkce STRING_SPLIT není dostupná.	Funkce STRING_SPLIT je dostupná na úrovni kompatibility 130 nebo vyšší. Pokud je úroveň kompatibility databáze nižší než 130, SQL Server nebude moct najít a spustit STRING_SPLIT funkci.

Opravy, které byly pod příznakem trasování 4199 ve starších verzích SQL Serveru před SQL Serverem 2016 (13.x), jsou teď ve výchozím nastavení povolené. S režimem kompatibility 130. Příznak trasování 4199 bude stále použitelný pro nové opravy optimalizátoru dotazů vydané po SQL Serveru 2016 (13.x). Pokud chcete použít starší optimalizátor dotazů ve službě SQL Database, musíte vybrat úroveň kompatibility 110. Informace o příznaku trasování 4199 naleznete v tématu Příznak trasování 4199.

Rozdíly mezi nižšími úrovněmi kompatibility a úrovní 120

Tato část popisuje nové chování zavedené s úrovní kompatibility 120.

Nastavení úrovně kompatibility 110 nebo nižší	Nastavení úrovně kompatibility 120
Používá se starší optimalizátor dotazů.	SQL Server 2014 (12.x) obsahuje významná vylepšení komponenty, která vytváří a optimalizuje plány dotazů. Tato nová funkce optimalizátoru dotazů závisí na použití úrovně kompatibility databáze 120. Nové databázové aplikace by měly být vyvinuty s využitím úrovně kompatibility databáze 120, aby bylo možné tato vylepšení využít. Aplikace migrované z dřívějších verzí SQL Serveru by měly být pečlivě testovány, aby bylo možné ověřit, že je zachován nebo vylepšen dobrý výkon. Pokud dojde ke snížení výkonu, můžete nastavit úroveň kompatibility databáze na 110 nebo starší, abyste použili starší metodologii optimalizátoru dotazů. Úroveň kompatibility databáze 120 používá nový estimátor kardinality, který je vyladěný pro moderní datové sklady a úlohy OLTP. Před nastavením úrovně kompatibility databáze na 110 z důvodu problémů s výkonem si přečtěte doporučení v části Plány dotazů v části Co je nového v SQL Serveru 2016.
V úrovních kompatibility nižších než 120 se nastavení jazyka při převodu hodnoty data na řetězcovou hodnotu ignoruje. Toto chování je specifické pouze pro typ data . Viz příklad B v části Příklady .	Nastavení jazyka se při převodu hodnoty data na řetězcovou hodnotu ignoruje.
Rekurzivní odkazy na pravé straně EXCEPT klauzule vytvářejí nekonečnou smyčku. Příklad C v části Příklady ukazuje toto chování.	Rekurzivní odkazy v EXCEPT klauzuli generují chybu v souladu se standardem ANSI SQL.
Rekurzivní společný výraz tabulky (CTE) umožňuje duplicitní názvy sloupců.	Rekurzivní CTE neumožňuje duplicitní názvy sloupců.
Zakázané triggery jsou povoleny, pokud jsou triggery změněny.	Změna triggeru nezmění stav (povoleno nebo zakázáno) triggeru.
Klauzule tabulky OUTPUT INTO ignoruje IDENTITY_INSERT SETTING = OFF a umožňuje vložení explicitních hodnot.	Explicitní hodnoty pro sloupec identity v tabulce nelze vložit, pokud IDENTITY_INSERT je nastavená hodnota VYPNUTO.
Pokud je kontejner databáze nastavený na částečnou hodnotu, může ověření $action pole v OUTPUT klauzuli MERGE příkazu vrátit chybu kolace.	Kolace hodnot vrácených $action klauzulí MERGE příkazu je kolace databáze místo kolace serveru a nevrátí se chyba konfliktu kolace.
Příkaz SELECT INTO vždy vytvoří operaci vložení s jedním vláknem.	Příkaz SELECT INTO může vytvořit paralelní operaci vložení. Při vkládání velkého počtu řádků může paralelní operace zvýšit výkon.

Rozdíly mezi nižšími úrovněmi kompatibility a úrovněmi 100 a 110

Tato část popisuje nové chování zavedené s úrovní kompatibility 110. Tato část se vztahuje také na úrovně kompatibility nad 110.

Nastavení úrovně kompatibility 100 nebo nižší	Nastavení úrovně kompatibility minimálně 110
Databázové objekty CLR (Common Language Runtime) se spouští s verzí 4 modulu CLR. Některé změny chování zavedené ve verzi 4 modulu CLR se však vyhýbají. Další informace najdete v tématu Co je nového v integraci CLR?	Databázové objekty CLR se spouští s verzí 4 modulu CLR.
XQuery funkce délka řetězce a podřetězce počítá každý náhradní řetězec jako dva znaky.	XQuery funkce délka řetězce a podřetězce počítá každý náhradní znak jako jeden znak.
PIVOT je povolen v rekurzivním dotazu CTE (Common Table Expression). Dotaz však vrátí nesprávné výsledky, pokud je na seskupení více řádků.	PIVOT není v rekurzivním dotazu CTE (Common Table Expression) povolený. Vrátí se chyba.
Algoritmus RC4 je podporován pouze pro zpětnou kompatibilitu. Nový materiál lze šifrovat pouze pomocí RC4 nebo RC4_128, pokud je databáze v kompatibilitě 90 nebo 100. (Nedoporučuje se.) V SYSTÉMU SQL Server 2012 (11.x) lze materiál zašifrovaný pomocí RC4 nebo RC4_128 dešifrovat v libovolné úrovni kompatibility.	Nový materiál nejde šifrovat pomocí RC4 nebo RC4_128. Místo toho použijte novější algoritmus, například jeden z algoritmů AES. V SYSTÉMU SQL Server 2012 (11.x) lze materiál zašifrovaný pomocí RC4 nebo RC4_128 dešifrovat v libovolné úrovni kompatibility.
Výchozí styl pro CAST datové typy CONVERT a datum a čas2 je 121, s výjimkou případů, kdy se ve výrazu počítaného sloupce používá některý z typů. Pro počítané sloupce je výchozí styl 0. Toto chování má vliv na počítané sloupce při jejich vytváření, použití v dotazech zahrnujících automatické parametrizace nebo použití v definicích omezení. Příklad D v části Příklady ukazuje rozdíl mezi styly 0 a 121. Nezobrazuje chování popsané výše. Další informace o stylech data a času naleznete v tématu CAST a CONVERT.	V rámci úrovně kompatibility 110 je výchozí styl pro CAST datové typy CONVERT a datum a čas2 vždy 121. Pokud váš dotaz spoléhá na staré chování, použijte úroveň kompatibility menší než 110 nebo explicitně zadejte styl 0 v ovlivněném dotazu. Upgrade databáze na úroveň kompatibility 110 nezmění uživatelská data uložená na disk. Tato data je nutné opravit ručně podle potřeby. Pokud jste například použili SELECT INTO k vytvoření tabulky ze zdroje, který obsahoval výše popsaný počítaný výraz sloupce, budou data (ve stylu 0) uložená místo samotné definice počítaného sloupce. Tato data byste museli ručně aktualizovat tak, aby odpovídala stylu 121.
Operátor + (Sčítání) lze použít na operand typu datum, čas, datum a čas2 nebo datetimeoffset , pokud druhý operand obsahuje typ datetime nebo smalldatetime.	Pokus o použití operátoru sčítání na operand typu datum, čas, datetime2 nebodatetimeoffset a operand typu datetime nebo smalldatetime způsobí chybu 402.
Všechny sloupce ve vzdálených tabulkách typu smalldatetime , na které se odkazuje v děleném zobrazení, se mapují jako datetime. Odpovídající sloupce v místních tabulkách (ve stejné pořadové pozici v seznamu výběrů) musí být typu datetime.	Všechny sloupce ve vzdálených tabulkách typu smalldatetime , na které se odkazuje v děleném zobrazení, se mapují jako smalldatetime. Odpovídající sloupce v místních tabulkách (ve stejné pořadové pozici v seznamu výběrů) musí být typu smalldatetime. Po upgradu na 110 se distribuované rozdělené zobrazení nezdaří kvůli neshodě datového typu. Tento problém můžete vyřešit změnou datového typu ve vzdálené tabulce na datum a čas nebo nastavením úrovně kompatibility místní databáze na 100 nebo nižší.
SOUNDEX funkce implementuje následující pravidla: 1) Velká písmena H nebo velká písmena W jsou ignorována při oddělení dvou souhlásek, které mají stejné číslo v SOUNDEX kódu. 2) Pokud první dva znaky character_expression mají stejné číslo v SOUNDEX kódu, jsou zahrnuty oba znaky. Jinak platí, že pokud má sada souběžných souhlásek stejné číslo v SOUNDEX kódu, jsou všechny vyloučeny s výjimkou první.	SOUNDEX funkce implementuje následující pravidla: 1) Pokud velká písmena H nebo velká písmena W oddělují dvě souhlásky, které mají stejné číslo v SOUNDEX kódu, bude souhláska vpravo ignorována. 2) Pokud sada souběžných souhlásek má stejné číslo v SOUNDEX kódu, jsou všechny vyloučeny s výjimkou první. Další pravidla můžou způsobit, že hodnoty vypočítané SOUNDEX funkcí se liší od hodnot vypočítaných v dřívějších úrovních kompatibility. Po upgradu na úroveň kompatibility 110 možná budete muset znovu sestavit indexy, haldy nebo omezení CHECK, která tuto funkci používají SOUNDEX . Další informace naleznete v tématu SOUNDEX.
STRING_AGGje k dispozici bez .<order_clause>	STRING_AGGje k dispozici s volitelným .<order_clause> Další informace najdete v tématu STRING_AGG

Rozdíly mezi úrovní kompatibility 90 a úrovní 100

Tato část popisuje nové chování zavedené s úrovní kompatibility 100.

Nastavení úrovně kompatibility 90	Nastavení úrovně kompatibility 100	Možnost dopadu
Nastavení QUOTED_IDENTIFIER je vždy nastaveno na zapnuto pro funkce s více hodnotami tabulky při jejich vytváření bez ohledu na nastavení na úrovni relace.	Nastavení relace QUOTED IDENTIFIER se respektuje při vytváření funkcí s více hodnotami tabulky.	Středně
Když vytvoříte nebo změníte funkci oddílu, vyhodnotí se literály datetime a smalldatetime v této funkci za předpokladu, že US_English jako nastavení jazyka.	Aktuální nastavení jazyka slouží k vyhodnocení literálů datetime a smalldatetime ve funkci oddílu.	Středně
Klauzule FOR BROWSE je povolená (a ignorována) v INSERT příkazech a SELECT INTO příkazech.	Klauzule FOR BROWSE není povolená v INSERT příkazech a SELECT INTO příkazech.	Středně
V klauzuli jsou povoleny predikáty fulltextu OUTPUT .	Predikáty fulltextu OUTPUT nejsou v klauzuli povolené.	Nízké
CREATE FULLTEXT STOPLIST, ALTER FULLTEXT STOPLISTa DROP FULLTEXT STOPLIST nejsou podporovány. Seznam stop systému se automaticky přidružuje k novým fulltextovým indexům.	CREATE FULLTEXT STOPLIST ALTER FULLTEXT STOPLIST a DROP FULLTEXT STOPLISTjsou podporovány.	Nízké
MERGE se nevynucuje jako vyhrazené klíčové slovo.	MERGE je plně rezervované klíčové slovo. Tento MERGE příkaz se podporuje na úrovni kompatibility 100 i 90.	Nízké
<dml_table_source> Použití argumentu příkazu INSERT vyvolá chybu syntaxe.	Výsledky klauzule OUTPUT můžete zaznamenat do vnořeného příkazu INSERT, UPDATE, DELETE nebo MERGE a vložit tyto výsledky do cílové tabulky nebo zobrazení. To se provádí pomocí <dml_table_source> argumentu příkazu INSERT.	Nízké
Není-li NOINDEX zadán DBCC CHECKDBDBCC CHECKTABLE nebo neprovádí kontroly fyzické i logické konzistence v jediné tabulce nebo indexovaném zobrazení a ve všech jeho neclusterovaných a XML indexech. Prostorové indexy se nepodporují.	Není-li NOINDEX zadán nebo DBCC CHECKDBDBCC CHECKTABLE neprovádí kontroly fyzické i logické konzistence v jedné tabulce a ve všech jejích neclusterovaných indexech. U indexů XML, prostorových indexů a indexovaných zobrazení se ale ve výchozím nastavení provádějí pouze kontroly fyzické konzistence. Pokud WITH EXTENDED_LOGICAL_CHECKS je zadána, logické kontroly se provádějí s indexovanými zobrazeními, indexy XML a prostorovými indexy, kde existují. Ve výchozím nastavení se kontroly fyzické konzistence provádějí před kontrolami logické konzistence. Pokud je zadán také NOINDEX, provádějí se pouze logické kontroly.	Nízké
Při použití klauzule OUTPUT s příkazem jazyka DML (Data Manipulat Language) a během provádění příkazu dojde k chybě za běhu, celá transakce se ukončí a vrátí zpět.	Pokud se OUTPUT klauzule používá s příkazem jazyka pro manipulaci s daty (DML) a během provádění příkazu dojde k chybě za běhu, chování závisí na SET XACT_ABORT nastavení. Pokud SET XACT_ABORT je vypnuto, příkaz přeruší chybu vygenerovanou příkazem DML pomocí OUTPUT klauzule ukončí příkaz, ale spuštění dávky pokračuje a transakce není vrácena zpět. Pokud SET XACT_ABORT je zapnuto, všechny chyby za běhu vygenerované příkazem DML pomocí klauzule OUTPUT ukončí dávku a transakce se vrátí zpět.	Nízké
Funkce CUBE a ROLLUP se nevynucují jako vyhrazená klíčová slova.	CUBE a ROLLUP jsou vyhrazená klíčová slova v klauzuli GROUP BY.	Nízké
Na elementy typu XML anyType se použije striktní ověření.	Laxní ověřování se použije u prvků typu anyType . Další informace naleznete v tématu Součásti se zástupnými výjimkou a ověřování obsahu.	Nízké
Speciální atributy xsi:nil a xsi:type nelze dotazovat ani upravovat příkazy jazyka pro manipulaci s daty. To znamená, že /e/@xsi:nil při ignorování atributů /e/@* a xsi:type dojde k chybě. Vrátí /e však atributy xsi:nil a xsi:type pro konzistenci s SELECT xmlCol, i když xsi:nil = "false".	Speciální atributy xsi:nil a xsi:type jsou uloženy jako běžné atributy a lze je dotazovat a upravovat. Například spuštění dotazu SELECT x.query('a/b/@*') vrátí všechny atributy včetně xsi:nil a xsi:type. Chcete-li vyloučit tyto typy v dotazu, nahraďte hodnotu @*@*[namespace-uri(.) != " URI ", nikoli (local-name(.) = "type" nebo local-name(.) ="nil".	Nízké
Uživatelem definovaná funkce, která převede hodnotu konstantního řetězce XML na typ data a času SQL Serveru je označena jako deterministická.	Uživatelem definovaná funkce, která převádí hodnotu konstantního řetězce XML na typ data a času SQL Serveru je označena jako nedeterministické.	Nízké
Sjednocení XML a typy seznamů nejsou plně podporované.	Typy sjednocení a seznamů jsou plně podporované, včetně následujících funkcí: Sjednocení seznamu Unie unie Seznam atomických typů Seznam sjednocení	Nízké
Možnosti SET vyžadované pro metodu xQuery se neověřují, pokud je metoda obsažena v zobrazení nebo vložené funkci s hodnotou tabulky.	Možnosti SET vyžadované pro metodu xQuery se ověřují, když je metoda obsažena v zobrazení nebo vložené funkci s hodnotou tabulky. Pokud jsou nesprávně nastaveny možnosti SET metody, vyvolá se chyba.	Nízké
Hodnoty atributů XML, které obsahují znaky konce řádku (návrat na začátek řádku a odřádkování), nejsou normalizovány podle standardu XML. To znamená, že oba znaky se vrátí místo jednoho znaku odřádkování.	Hodnoty atributů XML, které obsahují znaky konce řádku (návrat na začátek řádku a odřádkování), jsou normalizovány podle standardu XML. To znamená, že všechny konceřádkůchmm datům jsou všechny konce řádků v externích parsovaných entitách (včetně entity dokumentu) normalizovány tak, že přeloží #xD #xA se dvěma znaky a všechny #xD, za nimiž následují #xA na jeden znak #xA. Aplikace, které používají atributy k přenosu řetězcových hodnot obsahujících znaky na konci řádku, nebudou tyto znaky přijímat zpět při jejich odeslání. Chcete-li se vyhnout procesu normalizace, použijte číselné znakové entity XML ke kódování všech znaků na konci řádku.	Nízké
Vlastnosti ROWGUIDCOL sloupce a IDENTITY mohou být nesprávně pojmenovány jako omezení. Například příkaz CREATE TABLE T (C1 int CONSTRAINT MyConstraint IDENTITY) se spustí, ale název omezení se nezachová a není přístupný pro uživatele.	Vlastnosti ROWGUIDCOL sloupce a IDENTITY nelze je pojmenovat jako omezení. Vrátí se chyba 156.	Nízké
Aktualizace sloupců pomocí obousměrného přiřazení, jako UPDATE T1 SET @v = column_name = <expression> je například může vést k neočekávaným výsledkům, protože živá hodnota proměnné se dá použít v jiných klauzulích, jako WHERE je například klauzule a ON během provádění příkazu, místo počáteční hodnoty příkazu. To může způsobit, že významy predikátů se změní nepředvídatelně na základě jednotlivých řádků. Toto chování platí pouze v případě, že je úroveň kompatibility nastavená na 90.	Aktualizace sloupců pomocí obousměrného přiřazení vytváří očekávané výsledky, protože během provádění příkazu se přistupuje pouze k počáteční hodnotě příkazu sloupce.	Nízké
Přiřazení proměnné je povoleno v příkazu obsahujícím operátor nejvyšší úrovně UNION , ale vrací neočekávané výsledky. Další informace najdete v příkladu E.	Přiřazení proměnné není povoleno v příkazu obsahujícím operátor UNION nejvyšší úrovně. Vrátí se chyba 10734. Najděte navrhované přepsání v příkladu E.	Nízké
Funkce ODBC {fn CONVERT()} používá výchozí formát data jazyka. V některých jazycích je výchozím formátem YDM, což může vést k chybám převodu při kombinaci funkce CONVERT() s jinými funkcemi, například {fn CURDATE()}, které očekávají formát YMD.	Funkce {fn CONVERT()} ODBC používá styl 121 (formát YMD nezávislý na jazyce) při převodu na datové typy ODBC SQL_TIMESTAMP, SQL_DATE, SQL_TIME, SQLDATE, SQL_TYPE_TIME a SQL_TYPE_TIMESTAMP.	Nízké
Vnitřní objekty datetime, například DATEPART nevyžadují řetězcové vstupní hodnoty, aby byly platné literály datetime. Například SELECT DATEPART (year, '2007/05-30') se úspěšně zkompiluje.	Vnitřní objekty datetime, například DATEPART vyžadují řetězcové vstupní hodnoty, aby byly platné literály datetime. Při použití neplatného literálu datetime se vrátí chyba 241.	Nízké
Koncové mezery zadané v prvním vstupním parametru funkce REPLACE se oříznou, když je parametr typu char. Například v příkazu SELECT '<' + REPLACE(CONVERT(char(6), 'ABC '), ' ', 'L') + '>'je hodnota 'ABC ' nesprávně vyhodnocena jako 'ABC'.	Koncové mezery jsou vždy zachovány. U aplikací, které spoléhají na předchozí chování funkce, použijte RTRIM funkci při zadávání prvního vstupního parametru funkce. Například následující syntaxe reprodukuje chování SYSTÉMU SQL Server 2005: SELECT '<' + REPLACE(RTRIM(CONVERT(char(6), 'ABC ')), ' ', 'L') + '>'.	Nízké

Vyhrazená klíčová slova

Nastavení kompatibility také určuje klíčová slova vyhrazená databázovým strojem. Následující tabulka ukazuje vyhrazená klíčová slova, která jsou zavedena jednotlivými úrovněmi kompatibility.

Nastavení úrovně kompatibility	Vyhrazená klíčová slova
130	Je třeba určit.
120	Žádné.
110	WITHIN GROUP, TRY_CONVERT, SEMANTICKEYPHRASETABLE, , SEMANTICSIMILARITYDETAILSTABLESEMANTICSIMILARITYTABLE
100	CUBE, , MERGEROLLUP
90	EXTERNAL, PIVOT, UNPIVOT, , REVERTTABLESAMPLE

Na dané úrovni kompatibility obsahují vyhrazená klíčová slova všechna klíčová slova zavedená na této úrovni nebo pod danou úroveň. Například pro aplikace na úrovni 110 jsou všechna klíčová slova uvedená v předchozí tabulce vyhrazena. Na nižších úrovních kompatibility zůstávají klíčová slova úrovně 100 platnými názvy objektů, ale funkce jazyka úrovně 110 odpovídající těmto klíčovým slovům nejsou k dispozici.

Po zavedení zůstane klíčové slovo rezervované. Například rezervovaný pivot klíčového slova, který byl zaveden v úrovni kompatibility 90, je také vyhrazen v úrovních 100, 110 a 120.

Pokud aplikace používá identifikátor vyhrazený jako klíčové slovo pro úroveň kompatibility, aplikace selže. Chcete-li tento problém obejít, uzavřete identifikátor mezi hranatými závorkami ([]) nebo uvozovkami (""); Chcete-li například upgradovat aplikaci, která používá identifikátor EXTERNAL na úroveň kompatibility 90, můžete změnit identifikátor na nebo [EXTERNAL]"EXTERNAL".

Další informace naleznete v tématu Vyhrazená klíčová slova.

Povolení

Vyžaduje ALTER oprávnění k databázi.

Příklady

A. Změna úrovně kompatibility

Následující příklad změní úroveň AdventureWorks2022 kompatibility ukázkové databáze na 150, výchozí pro SQL Server 2019 (15.x).

ALTER DATABASE AdventureWorks2022
SET COMPATIBILITY_LEVEL = 150;
GO

Následující příklad vrátí úroveň kompatibility aktuální databáze.

SELECT name,
       compatibility_level
FROM sys.databases
WHERE name = db_name();
GO

B. Ignorujte příkaz SET LANGUAGE s výjimkou úrovně kompatibility 120 nebo vyšší.

Následující dotaz ignoruje příkaz s výjimkou úrovně kompatibility SET LANGUAGE 120 nebo vyšší.

SET DATEFORMAT dmy;

DECLARE @t2 AS DATE = '12/5/2011';

SET LANGUAGE dutch;

SELECT CONVERT (VARCHAR (11), @t2, 106);
GO

Výsledky, pokud je úroveň kompatibility menší než 120: 12 May 2011

Výsledky, pokud je úroveň kompatibility nastavená na 120 nebo vyšší: 12 mei 2011

C. Pro nastavení na úrovni kompatibility 110 nebo nižší rekurzivní odkazy na pravé straně klauzule EXCEPT vytvoří nekonečnou smyčku.

WITH cte AS
    (SELECT * FROM (VALUES (1), (2), (3)) AS v(a)),
    r AS (SELECT a
    FROM cte
UNION ALL
    (SELECT a FROM cte EXCEPT SELECT a FROM r))
SELECT a
FROM r;
GO

D. Rozdíl mezi styly 0 a 121

Pokud je úroveň kompatibility nižší než 110, výchozí styl pro operace s CAST datovými typy CONVERT a datetime2 je 121, s výjimkou případů, kdy je některý z typů použit ve výrazu počítaného sloupce. Pro počítané sloupce je výchozí styl 0.

Pokud je úroveň kompatibility 110 nebo vyšší, výchozí styl a CAST operace s CONVERT datovými typy čas a datetime2 je vždy 121. Další informace najdete v tématech Rozdíly mezi nižšími úrovněmi kompatibility a úrovněmi 100 a 110 .

Další informace o stylech data a času naleznete v tématu CAST a CONVERT.

DROP TABLE IF EXISTS t1;
GO

CREATE TABLE t1
(
    c1 TIME (7),
    c2 DATETIME2
);
GO

INSERT t1 (c1, c2)
VALUES (GETDATE(), GETDATE());
GO

SELECT CONVERT (NVARCHAR (16), c1, 0) AS TimeStyle0,
       CONVERT (NVARCHAR (16), c1, 121) AS TimeStyle121,
       CONVERT (NVARCHAR (32), c2, 0) AS Datetime2Style0,
       CONVERT (NVARCHAR (32), c2, 121) AS Datetime2Style121
FROM t1;
GO

Tato funkce vrátí výsledky, například následující:

TimeStyle0	TimeStyle121	Datetime2Style0	Datetime2Style121
3:15	15:15:35.8100000	7. června 2011 3:15	2011-06-07 15:15:35.8130000

E. Přiřazení proměnné – operátor UNION nejvyšší úrovně

V nastavení úrovně kompatibility databáze 90 je přiřazení proměnné povoleno v příkazu obsahujícím operátor UNION nejvyšší úrovně, ale vrací neočekávané výsledky. Například v následujících příkazech je místní proměnná @v přiřazena hodnota sloupce BusinessEntityID ze sjednocení dvou tabulek. Když příkaz SELECT vrátí více než jednu hodnotu, přiřadí se proměnné poslední vrácená hodnota. V tomto případě je proměnná správně přiřazena poslední hodnotu, ale vrátí se také sada výsledků příkazu SELECT UNION.

ALTER DATABASE AdventureWorks2022
SET COMPATIBILITY_LEVEL = 110;
GO

USE AdventureWorks2022;
GO

DECLARE @v AS INT;

SELECT @v = BusinessEntityID
FROM HumanResources.Employee
UNION ALL
SELECT @v = BusinessEntityID
FROM HumanResources.EmployeeAddress;

SELECT @v;

V nastavení úrovně kompatibility databáze 100 a vyšší není přiřazení proměnných povolené v příkazu obsahujícím operátor UNION nejvyšší úrovně. Vrátí se chyba 10734.

Pokud chcete chybu vyřešit, přepište dotaz, jak je znázorněno v následujícím příkladu.

DECLARE @v AS INT;

SELECT @v = BusinessEntityID
FROM (SELECT BusinessEntityID
      FROM HumanResources.Employee
      UNION ALL
      SELECT BusinessEntityID
      FROM HumanResources.EmployeeAddress) AS Test;

SELECT @v;

Související obsah

• Udržování stability výkonu během upgradu na novější SQL Server
• Změna úrovně kompatibility databáze a použití úložiště dotazů
• certifikace kompatibility
• ALTER DATABASE (Transact-SQL)
• Upgrade databází pomocí Pomocníka pro ladění dotazů
• Vytvořit databázi
• Zobrazení nebo změna úrovně kompatibility databáze
• Rady k úložišti dotazů