ALTER DATABASE (Transact-SQL) kompatibilitási szintje

A következőkre vonatkozik:SQL ServerAzure SQL DatabaseFelügyelt Azure SQL-példány

Beállítja Transact-SQL és lekérdezésfeldolgozási viselkedéseket, hogy kompatibilisek legyenek az SQL-motor megadott verziójával. További ALTER DATABASE-beállítások: ALTER DATABASE.

A szintaxisi konvenciókról további információt Transact-SQL szintaxiskonvenciákat.

Szemantika

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

Érvek

database_name

A módosítani kívánt adatbázis neve.

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

Az SQL Server azon verziója, amellyel az adatbázist kompatibilissé kell tenni. A következő kompatibilitási szintű értékek konfigurálhatók (nem minden verzió támogatja a fenti kompatibilitási szintet):

Termék	Adatbázismotor verziója	Alapértelmezett kompatibilitási szint megjelölése	Támogatott kompatibilitási szintértékek
Azure SQL Database	17	170	170, 160, 150, 140, 130, 120, 110, 100
Felügyelt Azure SQL-példány	16	150	160, 150, 140, 130, 120, 110, 100
SQL Server 2025 (17.x) előzetes verzió	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	150	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	Százhúsz	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

Fontos

Az SQL Server és az Azure SQL Database adatbázismotor-verziószámai nem hasonlíthatók össze egymással, és inkább belső buildszámok ezekhez a különálló termékekhez. Az Azure SQL Database adatbázismotorja ugyanazon a kódbázison alapul, mint az SQL Server adatbázismotorja. A legfontosabb, hogy az Azure SQL Database adatbázismotorja mindig a legújabb SQL-adatbázismotor-bitekkel rendelkezik. Az Azure SQL Database 12-es verziója újabb, mint az SQL Server 15-ös verziója.

Ajánlott eljárások az adatbázis-kompatibilitási szint frissítéséhez

A kompatibilitási szint frissítéséhez javasolt munkafolyamatot lásd: Teljesítménystabilitás megőrzése az újabb SQL Serverre való frissítés során. Emellett az adatbázis-kompatibilitási szint frissítésével kapcsolatos segítségért tekintse meg az adatbázisok frissítését a Lekérdezéshangolási segéd használatával.

Megjegyzések

Az SQL Server összes telepítése esetén az alapértelmezett kompatibilitási szint az adatbázismotor verziójához van társítva. Az új adatbázisok erre a szintre vannak beállítva, hacsak az model adatbázis nem rendelkezik alacsonyabb kompatibilitási szinttel. Az SQL Server bármely korábbi verziójából csatolt vagy visszaállított adatbázisok esetében az adatbázis megtartja a meglévő kompatibilitási szintjét, ha legalább az SQL Server adott példánya számára engedélyezett. Az adatbázismotor által megengedettnél alacsonyabb kompatibilitási szinttel rendelkező adatbázisok áthelyezése automatikusan az engedélyezett legalacsonyabb kompatibilitási szintre állítja az adatbázist. Ez a rendszer- és felhasználói adatbázisokra is vonatkozik.

Az SQL Server 2017 (14.x) esetében az alábbi viselkedések várhatók egy adatbázis csatolásakor vagy visszaállításakor, valamint egy helyszíni frissítés után:

• Ha egy felhasználói adatbázis kompatibilitási szintje a frissítés előtt 100 vagy annál magasabb volt, a frissítés után is ugyanaz marad.
• Ha egy felhasználói adatbázis kompatibilitási szintje a frissítés előtt 90 volt, a frissített adatbázisban a kompatibilitási szint 100-ra van állítva, ami az SQL Server 2017 legalacsonyabb támogatott kompatibilitási szintje (14.x).
• A , tempdb, modelés erőforrás-adatbázisok kompatibilitási msdbszintje egy adott adatbázismotor-verzió alapértelmezett kompatibilitási szintjére van állítva.
• A master rendszeradatbázis megőrzi a frissítés előtti kompatibilitási szintet. Ez nem befolyásolja a felhasználói adatbázis viselkedését.

Az alacsonyabb kompatibilitási szinteken futó, már meglévő adatbázisok esetében, ha az alkalmazásnak nem kell olyan fejlesztéseket használnia, amelyek csak magasabb adatbázis-kompatibilitási szinten érhetők el, a korábbi adatbázis-kompatibilitási szint fenntartása érvényes módszer. Ha új fejlesztési munkát szeretne végezni, vagy ha egy meglévő alkalmazáshoz olyan új funkciókra van szükség, mint az intelligens lekérdezésfeldolgozás az SQL-adatbázisokban és néhány új Transact-SQL, tervezze meg az adatbázis kompatibilitási szintjét a legújabb rendelkezésre állóra frissíteni. További információ: Kompatibilitási szintek és adatbázismotor-frissítések.

Megjegyzés:

Ha nincsenek felhasználói objektumok és függőségek, általában biztonságosan frissíthet az alapértelmezett kompatibilitási szintre. További információ: Javaslatok – főadatbázis.

Az adatbázis kompatibilitási szintjének módosítására használható ALTER DATABASE . Az adatbázis új kompatibilitási szintje a parancsok kiadásakor USE <database> lép érvénybe, vagy egy új bejelentkezést dolgoz fel az adatbázissal alapértelmezett adatbázis-környezetként.

Az adatbázis aktuális kompatibilitási szintjének megtekintéséhez kérdezze le az compatibility_level oszlopot a sys.databases katalógusnézetben.

Az SQL Server egy korábbi verziójában létrehozott és AZ SQL Server 2016 (13.x) RTM-re vagy Service Pack 1-re frissített terjesztési adatbázis kompatibilitási szintje 90, ami más adatbázisok esetében nem támogatott. Ez nincs hatással a replikáció működésére. A későbbi szervizcsomagokra és az SQL Server verzióira való frissítés esetén a terjesztési adatbázis kompatibilitási szintje az adatbázis kompatibilitási szintjének növekedéséhez master vezet.

Ha egy adatbázis 120-es vagy újabb kompatibilitási szintjét szeretné használni egy adatbázis esetében, de az SQL Server 2012 (11.x) számosságbecslési modelljét, amely a 110-es adatbáziskompatibilitási szintre van leképezve, tekintse meg az ALTER DATABASE SCOPED CONFIGURATION-t, és különösen annak kulcsszóját LEGACY_CARDINALITY_ESTIMATION = ON.

Megjegyzések az Azure SQL-hez

Az alapértelmezett kompatibilitási szint az Azure SQL Database-ben és a Microsoft Fabricben található SQL Database-ben újonnan létrehozott adatbázisok esetében 170.

Az alapértelmezett kompatibilitási szint 150 az újonnan létrehozott adatbázisokhoz az Azure SQL Managed Instance ajánlat SQL Server 2022 frissítési szabályzatában .

Az alapértelmezett kompatibilitási szint 170 az újonnan létrehozott adatbázisokhoz az Azure SQL Managed Instance ajánlat Always-up-todátumfrissítési szabályzatában .

A Microsoft nem frissíti automatikusan a meglévő adatbázisok adatbázis-kompatibilitási szintjét. Ezt az ügyfelek saját belátásuk szerint tehetik meg.

A Microsoft erősen javasolja, hogy az ügyfelek a legújabb kompatibilitási szintre frissítsenek a lekérdezésoptimalizálás legújabb fejlesztései érdekében. Az Azure SQL Database két különböző kompatibilitási szintje közötti legfontosabb lekérdezések teljesítménybeli különbségeinek felmérésére vonatkozó tippekért tekintse meg a Továbbfejlesztett lekérdezési teljesítményt az Azure SQL Database 130-es kompatibilitási szintjével. Ez a cikk a 130-es kompatibilitási szintre és az SQL Serverre vonatkozik, de ugyanez a módszer vonatkozik az SQL Server és az Azure SQL Database 140-es vagy magasabb szintű frissítésére is.

Az Azure SQL Database nem támogatja a kompatibilitási szinttől függően eltérő funkciókat.

Az aktuális kompatibilitási szint megkeresése

Az aktuális kompatibilitási szint meghatározásához kérdezze le a compatibility_levelsys.databases oszlopát.

SELECT [name],
       compatibility_level
FROM sys.databases;

Az adatbázismotor azon verziójának meghatározásához, amelyhez csatlakozik, hajtsa végre a következő lekérdezést.

SELECT SERVERPROPERTY('ProductVersion');

Kompatibilitási szintek és adatbázismotor-frissítések

Az adatbázis-kompatibilitási szint értékes eszköz az adatbázisok modernizálásához azáltal, hogy lehetővé teszi az SQL Server adatbázismotor frissítését, miközben az alkalmazások csatlakoztatásának működési állapotát ugyanazzal az adatbázis-kompatibilitási szinttel tartja fenn. Ez azt jelenti, hogy az SQL Server egy régebbi verziójáról (például AZ SQL Server 2008 (10.0.x)) frissíthető AZ SQL Serverre vagy az Azure SQL Database-re (beleértve a felügyelt Azure SQL-példányt is) alkalmazásmódosítás nélkül (az adatbázis-kapcsolat kivételével). További információ: Kompatibilitási minősítés.

Mindaddig, amíg az alkalmazásnak nem kell olyan fejlesztéseket használnia, amelyek csak magasabb adatbázis-kompatibilitási szinten érhetők el, érvényes módszer az SQL Server adatbázismotor frissítésére és a korábbi adatbázis-kompatibilitási szint fenntartására. A kompatibilitási szint visszamenőleges kompatibilitáshoz való használatával kapcsolatos további információkért lásd a kompatibilitási minősítést.

Kompatibilitási szintek és tárolt eljárások

Egy tárolt eljárás végrehajtásakor annak az adatbázisnak az aktuális kompatibilitási szintjét használja, amelyben definiálva van. Az adatbázis kompatibilitási beállításainak módosításakor az összes tárolt eljárás automatikusan újrafordításra kerül.

Kompatibilitási szint használata a visszamenőleges kompatibilitáshoz

Az adatbázis-kompatibilitási szint beállítása visszamenőleges kompatibilitást biztosít az SQL Server korábbi verzióival abban az esetben, ha a Transact-SQL és a lekérdezésoptimalizálási viselkedés csak a megadott adatbázisra vonatkozik, a teljes kiszolgálóra nem.

A 130-es kompatibilitási módtól kezdve a javításokat és funkciókat érintő új lekérdezési terveket szándékosan csak az új kompatibilitási szintre adták hozzá. Ez azért történt, hogy a lekérdezési terv új optimalizálási viselkedése által esetleg bevezetett változások miatt a teljesítménycsökkenésből eredő frissítések során minimálisra csökkenjen a kockázat.

Alkalmazás szempontjából az alacsonyabb kompatibilitási szintet használja biztonságosabb migrálási útvonalként a verzióeltérések megoldásához, a megfelelő kompatibilitási szint beállítás által szabályozott viselkedésekben. A cél továbbra is az, hogy valamikor a legújabb kompatibilitási szintre frissítsen, hogy örököljön néhány új funkciót, például az SQL-adatbázisok intelligens lekérdezésfeldolgozását, de ezt szabályozott módon végezze el.

További információkért, beleértve az adatbázis-kompatibilitási szint frissítéséhez ajánlott munkafolyamatot, tekintse meg az adatbázis-kompatibilitási szint frissítésének ajánlott eljárásait.

• Egy adott SQL Server-verzióban bevezetett megszűnt funkciók kompatibilitási szinttel nem védettek. Ez az SQL Server adatbázismotorból eltávolított funkciókra vonatkozik. A tippet például megszüntették az FASTFIRSTROW SQL Server 2012-ben (11.x), és lecserélték a OPTION (FAST n ) tippre. Ha az adatbázis kompatibilitási szintjét 110-esre állítja, az nem állítja vissza a megszűnt tippet. A megszűnt funkciókról további információt az SQL Server megszűnt adatbázismotor-funkcióiban talál.

• Előfordulhat, hogy egy adott SQL Server-verzióban bevezetett kompatibilitási változásokkompatibilitási szinttel nem védettek. Ez az SQL Server adatbázismotor verziói közötti viselkedésváltozásokra vonatkozik. Transact-SQL viselkedést általában kompatibilitási szint védi. A módosított vagy eltávolított rendszerobjektumokat azonban nem védi a kompatibilitási szint.

  A kompatibilitási szint által védett kompatibilitástörő változásra példa a datetime-ről datetime2 adattípusokra történő implicit átalakítás. A 130-es adatbázis-kompatibilitási szinten ezek jobb pontosságot mutatnak a tört ezredmásodpercek számba adásával, ami eltérő konvertált értékeket eredményez. A korábbi konverziós viselkedés visszaállításához állítsa az adatbázis kompatibilitási szintjét 120-ra vagy alacsonyabbra.

  A kompatibilitási szint által nem védett kompatibilitási szintű kompatibilitástörő változások például a következők:

  • Módosított oszlopnevek a rendszerobjektumokban. Az SQL Server 2012 -ben (11.x) a benne lévő single_pages_kb oszlop sys.dm_os_sys_info átnevezve lettpages_kb. A kompatibilitási szinttől függetlenül a lekérdezés SELECT single_pages_kb FROM sys.dm_os_sys_info a 207-es hibát fogja eredményezni (érvénytelen oszlopnév).

  • Eltávolított rendszerobjektumok. Az SQL Server 2012 -ben (11.x) a rendszer eltávolította.sp_dboption A kompatibilitási szinttől függetlenül az utasítás EXEC sp_dboption 'AdventureWorks2022', 'autoshrink', 'FALSE'; 2812-es (Could not find stored procedure 'sp_dboption') hibát eredményez.

    További információ a kompatibilitástörő változásokról:

    • Az SQL Server 2019 adatbázismotor-funkcióinak kompatibilitástörő változásai
    • Az adatbázismotor funkcióinak kompatibilitástörő változásai az SQL Server 2017-ben
    • Az SQL Server 2016 adatbázismotor-funkcióinak kompatibilitástörő változásai

Kompatibilitási szintek közötti különbségek

Az SQL Server összes telepítése esetén az alapértelmezett kompatibilitási szint az adatbázismotor verziójához van társítva, ahogyan az ebben a táblázatban látható. Az új fejlesztési munkákhoz mindig a legújabb adatbáziskompatibilitási szinten tervezze meg az alkalmazások minősítését.

Az új Transact-SQL szintaxist nem az adatbázis kompatibilitási szintje határozza meg, kivéve, ha a meglévő alkalmazásokat a felhasználói Transact-SQL kóddal való ütközés létrehozásával szakíthatják meg. Ezek a kivételek a cikk következő szakaszaiban találhatók, amelyek az egyes kompatibilitási szintek közötti különbségeket ismertetik.

Az adatbázis-kompatibilitási szint az SQL Server korábbi verzióival való visszamenőleges kompatibilitást is biztosít, mivel az SQL Server bármely korábbi verziójából csatolt vagy visszaállított adatbázisok megőrzik a meglévő kompatibilitási szintet (ha megegyeznek vagy magasabbak a minimálisan engedélyezett kompatibilitási szintnél). Ezt a cikk visszafelé kompatibilitási szinttel foglalkozó szakaszában tárgyaltuk.

A 130-es adatbáziskompatibilitási szinttől kezdve a lekérdezési csomagokat érintő új javítások és funkciók csak a legújabb elérhető kompatibilitási szintre lettek hozzáadva, más néven az alapértelmezett kompatibilitási szintre. Ez azért történt, hogy minimalizálja a lekérdezéstervek változásai miatt a teljesítménycsökkenésből eredő frissítések kockázatát, amelyet új lekérdezésoptimalizálási viselkedések vezethetnek be.

Az adatbázismotor új verziójának alapértelmezett kompatibilitási szintjéhez hozzáadott alapvető tervre hatással lévő módosítások a következők:

1. A 4199-es nyomkövetési jelző alatt kiadott korábbi SQL Server-verziókhoz kiadott lekérdezésoptimalizáló-javítások automatikusan engedélyezve lesznek egy újabb SQL Server-verzió alapértelmezett kompatibilitási szintjén.

   A következőkre vonatkozik: SQL Server (az SQL Server 2016-os (13.x) verziótól kezdve), Azure SQL Database.

   Amikor például az SQL Server 2016 (13.x) kiadásra került, a korábbi SQL Server-verziókhoz (és a megfelelő 100–120-es kompatibilitási szintekhez) kiadott lekérdezésoptimalizáló-javítások automatikusan engedélyezve lettek az SQL Server 2016 (13.x) alapértelmezett kompatibilitási szintjét (130) használó adatbázisok esetében. Csak az RTM utáni lekérdezésoptimalizáló javításokat kell explicit módon engedélyezni.

   A Lekérdezésoptimalizáló-javítások engedélyezéséhez az alábbi módszereket használhatja:

   • Kiszolgálószinten a 4199-es nyomkövetési jelzővel.
   • Az adatbázis szintjén az QUERY_OPTIMIZER_HOTFIXESALTER DATABASE SCOPED CONFIGURATION (Transact-SQL) beállítással.
   • A lekérdezés szintjén a USE HINT 'ENABLE_QUERY_OPTIMIZER_HOTFIXES' módosítsa a lekérdezést.
   • A lekérdezés szintjén, kódmódosítások USE HINT 'ENABLE_QUERY_OPTIMIZER_HOTFIXES' nélkül, a Lekérdezéstár tippek funkcióval.

   Később, amikor az SQL Server 2017 (14.x) megjelent, az SQL Server 2016 (13.x) RTM automatikusan engedélyezve lett az SQL Server 2017 (14.x) alapértelmezett kompatibilitási szintet (140) használó adatbázisok esetében. Ez egy kumulatív viselkedés, amely az összes korábbi verziójavítást is tartalmazza. Ismét csak az RTM-alapú lekérdezésoptimalizáló utáni javításokat kell explicit módon engedélyezni.

   Az alábbi táblázat összefoglalja ezt a viselkedést:

   Adatbázismotor (DE) verziója	Adatbázis-kompatibilitási szint	TF 4199	QO-változások az összes korábbi adatbáziskompatibilitási szintről	QO-módosítások az RTM utáni (DE) verzióhoz
   13 (SQL Server 2016 (13.x))	100–120 130	Kikapcsolva Bekapcsolva Kikapcsolva Bekapcsolva	Letiltva Bekapcsolva Engedélyezve Bekapcsolva	Fogyatékos Bekapcsolva Fogyatékos Bekapcsolva
   14 (SQL Server 2017 (14.x))	100–120 130 140	Kikapcsolva Bekapcsolva Kikapcsolva Bekapcsolva Kikapcsolva Bekapcsolva	Letiltva Bekapcsolva Engedélyezve Bekapcsolva Engedélyezve Bekapcsolva	Fogyatékos Bekapcsolva Fogyatékos Bekapcsolva Fogyatékos Bekapcsolva
   15 (SQL Server 2019 (15.x)) és (Azure SQL Database)	100–120 130–140 150	Kikapcsolva Bekapcsolva Kikapcsolva Bekapcsolva Kikapcsolva Bekapcsolva	Letiltva Bekapcsolva Engedélyezve Bekapcsolva Engedélyezve Bekapcsolva	Fogyatékos Bekapcsolva Fogyatékos Bekapcsolva Fogyatékos Bekapcsolva
   16 (SQL Server 2022 (16.x)) és (Azure SQL Database)	100–120 130–150 160	Kikapcsolva Bekapcsolva Kikapcsolva Bekapcsolva Kikapcsolva Bekapcsolva	Letiltva Bekapcsolva Engedélyezve Bekapcsolva Engedélyezve Bekapcsolva	Fogyatékos Bekapcsolva Fogyatékos Bekapcsolva Fogyatékos Bekapcsolva
   17 (SQL Server 2025 (17.x) előzetes verzió, Azure SQL Database és SQL Database a Microsoft Fabricben)	100–120 130–160 170	Kikapcsolva Bekapcsolva Kikapcsolva Bekapcsolva Kikapcsolva Bekapcsolva	Letiltva Bekapcsolva Engedélyezve Bekapcsolva Engedélyezve Bekapcsolva	Fogyatékos Bekapcsolva Fogyatékos Bekapcsolva Fogyatékos Bekapcsolva

   A lekérdezésoptimalizáló olyan javításokat javít, amelyek a hibás eredményeket vagy a hozzáférés-megsértési hibákat nem védik a 4199-ben megadott nyomkövetési jelzővel. Ezek a javítások nem tekinthetők opcionálisnak.

2. A Microsoft Fabricben az SQL Serveren, az Azure SQL Database-ben és az SQL Database-ben kiadott számosságbecslő módosításai csak az új adatbázismotor-verzió alapértelmezett kompatibilitási szintjén engedélyezettek, a korábbi kompatibilitási szinteken azonban nem.

   Például az SQL Server 2016 (13.x) kiadásakor a számosságbecslési folyamat módosításai csak az SQL Server 2016 (13.x) alapértelmezett kompatibilitási szintjét (130) használó adatbázisok esetében voltak elérhetők. A korábbi kompatibilitási szintek megtartották az SQL Server 2016 (13.x) előtt elérhető számosságbecslési viselkedést.

   Később, amikor az SQL Server 2017 (14.x) megjelent, a számosságbecslési folyamat újabb módosításai csak az SQL Server 2017 (14.x) alapértelmezett kompatibilitási szintet (140) használó adatbázisok esetében voltak elérhetők. A 130-es adatbázis-kompatibilitási szint megtartotta az SQL Server 2016 (13.x) számosságbecslési viselkedését.

   Az alábbi táblázat összefoglalja ezt a viselkedést:

   Adatbázismotor verziója	Adatbázis-kompatibilitási szint	A CE új verziójának változásai
   13 (SQL Server 2016 (13.x))	< 130 130	Fogyatékos Bekapcsolva
   14 (SQL Server 2017 (14.x))1	< 140 140	Fogyatékos Bekapcsolva
   15 (SQL Server 2019 (15.x))1	< 150 150	Fogyatékos Bekapcsolva
   16 (SQL Server 2022 (16.x))1	< 160 160	Fogyatékos Bekapcsolva
   17 (SQL Server 2025 (17.x) előzetes verzió)1	< 170 170	Fogyatékos Bekapcsolva

   ¹ Az Azure SQL Database-hez és a Microsoft Fabric sql-adatbázisához is alkalmazható.

A cikk következő szakaszaiban további különbségek érhetők el az egyes kompatibilitási szintek között.

A 160-es és a 170-es szintű kompatibilitási szint közötti különbségek

Ez a szakasz a 170-es kompatibilitási szinttel bevezetett új viselkedéseket ismerteti.

Kompatibilitási szint beállítása 160 vagy annál alacsonyabb	170 kompatibilitási szint beállítása
A szimmetrikus kulcs, az adatbázis-főkulcs és a szolgáltatás-főkulcs kulcsának védelme érdekében az SQL Server és az Azure SQL titkosított formában tárolja a kulcsanyagot. A titkosítás PKCS#1 v1.5 párnázási módot használ.	A szimmetrikus kulcs, az adatbázis-főkulcs és a szolgáltatás-főkulcs kulcsának védelme érdekében az SQL Server és az Azure SQL titkosított formában tárolja a kulcsanyagot. A titkosítás OAEP-256 párnázási módot használ. A dm_database_encryption_keys a encryptor_type jelenik meg ahelyettCERTIFICATE_OAEP_256, hogy CERTIFICATE a .
A reguláris kifejezések összetett minták egyeztetésére és az SQL Server és az Azure SQL Database adatainak kezelésére használhatók. A T-SQL-ben rendszeres kifejezéstámogatás lett hozzáadva. Néhány reguláris kifejezésfüggvény nem érhető el minden adatbáziskompatibilitási szinten. További információ: Reguláris kifejezésfüggvények.	Az olyan reguláris kifejezési függvények, mint a REGEXP_LIKE, a REGEXP_MATCHES és a REGEXP_SPLIT_TO_TABLE, lehetővé teszik a mintaegyeztetést, a kinyerést és a felosztást közvetlenül a T-SQL-ben.
Az adatbázismotor hozzáadta az AI-beágyazások (vektortömbök) szövegkifejezésekből való létrehozását. További információ: AI-függvények.	Bevezeti a AI_GENERATE_CHUNKS függvényt, amely lehetővé teszi a szöveges bemenetek adatbeírását az AI-modellek használatához, javítva az AI-szolgáltatásokkal való integrációt.
Az adatbázismotor hagyományosan úgy védi a DML-utasításokat a Halloween-probléma ellen, hogy bevesz egy Spool operátort a lekérdezési tervbe, vagy kihasználja a tervben már meglévő másik blokkoló operátort, például a rendezést vagy a kivonategyezést.	Az optimalizált Halloween-védelem eltávolítja a szükségtelen dobósor-kezelőket, és javítja a lekérdezési teljesítményt olyan DML-műveletek során, ahol Halloween-védelemre van szükség.
A paraméteres lekérdezések több gyorsítótárazott lekérdezési tervvel is rendelkezhetnek egy paraméter különböző szelektivitási kategóriáihoz. A paraméterérzékeny csomagok optimalizálása alapértelmezés szerint engedélyezve van a 160-es kompatibilitási szinten csak a lekérdezések kiválasztásához	Ha a paraméterérzékeny csomag optimalizálása a 170-es kompatibilitási szinten működik, a DML-lekérdezések támogatása és támogatása tempdb is elérhető
A paraméteres lekérdezések, amelyek opcionális paraméterekkel rendelkeznek, a paraméterek szippantása miatt az optimálisnál rosszabb tervek is előfordulhatnak.	Lekérdezésterv optimalizálása választható paraméterek esetén, a teljesítmény javítása a NULL és a nem NULL értékekhez megfelelőbb tervek létrehozásával.

A 150-es és a 160-es szintű kompatibilitási szint közötti különbségek

Ez a szakasz a 160-es kompatibilitási szinttel bevezetett új viselkedéseket ismerteti.

150-es vagy alacsonyabb kompatibilitási szint beállítása	160 kompatibilitási szint beállítása
A paraméteres lekérdezések egyetlen lekérdezési tervvel rendelkeznek az első végrehajtáshoz használt paraméterek alapján. A rendszer csak egy lekérdezési tervet gyorsítótáraz és használ az összes paraméterértékhez. Ez azt okozhatja, hogy a lekérdezéstervek nem hatékonyak a paraméter egyes értékeinél, más néven paraméterérzékeny tervnél.	A paraméteres lekérdezések több gyorsítótárazott lekérdezési tervvel is rendelkezhetnek egy paraméter különböző szelektivitási kategóriáihoz. A paraméterérzékeny csomagok optimalizálása alapértelmezés szerint engedélyezve van a 160-es kompatibilitási szinten. További információ: PSP Optimization.
A számosságbecslés csak egy alapértelmezett modellfeltevés-készletet használ az összes adatbázis és lekérdezés alapjául szolgáló adateloszlási és használati mintákról. Ezen feltételezések bármelyikének módosítására vagy módosítására csak akkor van lehetőség, ha a felhasználó egy manuális folyamatot hajt végre, amely explicit módon jelzi, hogy mely modellfeltevéseket kell használni lekérdezési tippek használatával. A lekérdezési terv létrehozása után nem lehet belső módosítást végezni ezen alapértelmezett modellen.	A számosság becslése az alapul szolgáló adateloszlási és használati mintákra vonatkozó alapértelmezett modellfeltevések készletével kezdődik, de egy adott lekérdezés végrehajtása után az adatbázismotor megtanulja, hogy a modellfeltevések mely készletei adhatnak pontosabb becslést, ezért a használt feltételezéseket úgy módosítja, hogy jobban megfeleljenek a lekérdezett adatkészletnek. A CE-visszajelzés alapértelmezés szerint engedélyezve van a 160-es kompatibilitási szinten. További információ: számosságbecslés (CE) visszajelzése.
Az adatbázismotor nem kísérli meg automatikusan meghatározni a párhuzamosság optimális fokát. A példány, adatbázis, lekérdezés vagy számítási feladat szintjén a párhuzamosság maximális fokának (MAXDOP) manuális szabályozásával kapcsolatos információkért lásd : Kiszolgálókonfiguráció: a párhuzamosság maximális foka	A párhuzamosság foka (DOP) A visszajelzések növelik a lekérdezés teljesítményét azáltal, hogy azonosítják az ismétlődő lekérdezések párhuzamossági hatékonysági hiányosságait az eltelt idő és várakozás alapján. Ha a párhuzamosság használata nem hatékony, a DOP-visszajelzés csökkenti a lekérdezés következő végrehajtásához szükséges DOP-t a konfigurált DOP-ból, és ellenőrzi, hogy segít-e. A DOP-visszajelzés alapértelmezés szerint nincs engedélyezve. A DOP-visszajelzés engedélyezéséhez engedélyezze az DOP_FEEDBACK adatbázis hatókörébe tartozó konfigurációt egy adatbázisban. További információ: A párhuzamosság foka (DOP) visszajelzése.

A 140-es és a 150-es szintű kompatibilitási szint közötti különbségek

Ez a szakasz a 150-es kompatibilitási szinttel bevezetett új viselkedéseket ismerteti.

140-es vagy alacsonyabb kompatibilitási szint beállítása	150 kompatibilitási szint beállítása
Előfordulhat, hogy a relációs adattárház és az elemzési számítási feladatok nem tudnak oszlopcentrikus indexeket használni az OLTP többletterhelése, a szállítói támogatás hiánya vagy más korlátozások miatt. Oszlopcentrikus indexek nélkül ezek a számítási feladatok nem tudják kihasználni a kötegelt végrehajtási módot.	A kötegelt végrehajtási mód mostantól oszlopcentrikus indexek nélkül érhető el elemzési számítási feladatokhoz. További információ: batch mód a rowstore-on.
Azok a sor módú lekérdezések, amelyek nem elegendő memóriakiadási méretet kérnek, amelyek a lemezre történő kiömlést eredményeznek, továbbra is problémákat tapasztalhatnak az egymást követő végrehajtásokkal kapcsolatban.	Az olyan sor módú lekérdezések, amelyek nem elegendő memóriakiadási méretet kérnek, amelyek a lemezre történő kiömlést eredményeznek, jobb teljesítményt jelenthetnek az egymást követő végrehajtások esetén. További információ: sor módú memóriahasználati visszajelzés.
Azok a sor módú lekérdezések, amelyek túlzott memóriakiadási méretet kérnek, amelyek egyidejűségi problémákat eredményeznek, továbbra is problémákat tapasztalhatnak az egymást követő végrehajtásokkal kapcsolatban.	Az egyidejűségi problémákat eredményező túlzott memóriakiadási méretet kérő sormódú lekérdezések jobb egyidejűséget eredményezhetnek az egymást követő végrehajtások során. További információ: sor módú memóriahasználati visszajelzés.
A T-SQL skaláris UDF-ekre hivatkozó lekérdezések iteratív meghívást használnak, nincs költségszámítás és kényszerítik a soros végrehajtást.	A T-SQL skaláris UDF-ek egyenértékű relációs kifejezésekké alakulnak át, amelyek "beágyazottak" a hívó lekérdezésbe, ami gyakran jelentős teljesítménynövekedést eredményez. További információ: T-SQL skaláris UDF-formázás.
A táblaváltozók rögzített becslést használnak a számosság becsléséhez. Ha a sorok tényleges száma sokkal magasabb a kitalált értéknél, az alsóbb rétegbeli műveletek teljesítménye szenvedhet.	Az új tervek a táblaváltozó tényleges számosságát használják, amelyet az első összeállításkor észleltek a rögzített becslés helyett. További információ: táblaváltozó halasztott fordítása.

A 150-es adatbázis-kompatibilitási szinten engedélyezett lekérdezésfeldolgozási funkciókkal kapcsolatos további információkért tekintse meg az SQL Server 2019 újdonságait és az INTELLIGENS lekérdezésfeldolgozást az SQL-adatbázisokban.

A kompatibilitási szint és a 140-es szint közötti különbségek

Ez a szakasz a 140-es kompatibilitási szinttel bevezetett új viselkedéseket ismerteti.

Kompatibilitási szint beállítása 130 vagy annál alacsonyabb	140 kompatibilitási szint beállítása
A többutas táblaértékű függvényekre hivatkozó utasítások számossági becslései rögzített sorbecslést használnak.	A többutas táblaértékű függvényekre hivatkozó jogosult utasítások számossági becslései a függvény kimenetének tényleges számosságát használják. Ez többutas táblaértékű függvények interleaved végrehajtásával engedélyezve van.
Előfordulhat, hogy a köteg módú lekérdezések, amelyek nem megfelelő memóriakiadási méreteket kérnek, amelyek a lemezre történő kiömlést eredményeznek, továbbra is problémákat tapasztalhatnak az egymást követő végrehajtásokkal kapcsolatban.	Az olyan kötegelt módú lekérdezések, amelyek nem elegendő memóriakiadási méretet kérnek, amelyek a lemezre történő kiömlést eredményeznek, jobb teljesítményt jelenthetnek az egymást követő végrehajtások során. Ez kötegelt módú memóriahasználati visszajelzéssel engedélyezve van, amely frissíti a gyorsítótárazott terv memóriahasználati méretét, ha kiömlött a batch mód operátorai számára.
Az egyidejűségi problémákat eredményező, túlzott memóriakiadási méretet kérő kötegelt módú lekérdezések továbbra is problémákat tapasztalhatnak az egymást követő végrehajtásokkal kapcsolatban.	Az egyidejűségi problémákat eredményező túlzott memóriakiadási méretet kérő kötegelt módú lekérdezések jobb egyidejűséget eredményezhetnek az egymást követő végrehajtások esetén. Ez kötegelt módú memóriahasználati visszajelzéssel engedélyezve van, amely frissíti a gyorsítótárazott csomag memóriakiadási méretét, ha eredetileg túlzott összeget kértek.
Az illesztő operátorokat tartalmazó kötegelt módú lekérdezések három fizikai illesztő algoritmusra jogosultak, beleértve a beágyazott hurkot, a kivonat illesztését és az egyesítési illesztéseket. Ha a számosságbecslések helytelenek az illesztésbemenetekhez, előfordulhat, hogy nem megfelelő illesztő algoritmust választ ki. Ha ez bekövetkezik, a teljesítmény romlik, és a nem megfelelő illesztési algoritmus a gyorsítótárazott terv újrafordításáig használatban marad.	Van egy további illesztési operátor, az úgynevezett adaptív illesztés. Ha a számosságbecslések helytelenek a külső buildillesztés bemenetéhez, előfordulhat, hogy nem megfelelő illesztő algoritmus van kiválasztva. Ha ez történik, és az utasítás jogosult adaptív illesztésre, a rendszer beágyazott hurkot használ a kisebb illesztési bemenetekhez, a kivonat illesztése pedig dinamikusan, újrafordítás nélkül használható a nagyobb illesztési bemenetekhez.
Az oszlopcentrikus indexekre hivatkozó triviális tervek nem jogosultak kötegelt módú végrehajtásra.	A rendszer elvet egy oszlopcentrikus indexekre hivatkozó triviális tervet egy olyan terv javára, amely jogosult kötegelt módú végrehajtásra.
Az sp_execute_external_script UDX-operátor csak sor módban futtatható.	Az sp_execute_external_script UDX-operátor jogosult kötegelt módú végrehajtásra.
A többutas táblaértékű függvények (TVF-ek) nem rendelkeznek interaktív végrehajtással	Többutas TVF-k interleaved végrehajtása a tervminőség javítása érdekében.

Az SQL Server 2017 előtti korábbi verzióiban a 4199-ben nyomkövetési jelző alatt lévő javítások alapértelmezés szerint engedélyezve vannak. A kompatibilitási mód 140. A nyomkövetési jelző 4199 továbbra is alkalmazható lesz az SQL Server 2017 után kiadott új lekérdezésoptimalizáló-javításokra. A Nyomkövetési jelző 4199-ről további információt a 4199-ben található nyomkövetési jelzőben talál.

A 120-es és a 130-es szintű kompatibilitási szint közötti különbségek

Ez a szakasz a 130-es kompatibilitási szinttel bevezetett új viselkedéseket ismerteti.

Kompatibilitási szint beállítása 120 vagy annál alacsonyabb	130 kompatibilitási szint beállítása
Az INSERT egy INSERT-SELECT utasításban egyszálas.	Az INSERT egy INSERT-SELECT utasításban többszálú, vagy párhuzamos tervvel rendelkezhet.
A memóriaoptimalizált táblák lekérdezései egyszálasan futnak.	A memóriaoptimalizált táblák lekérdezései mostantól párhuzamos csomagokat tartalmazhatnak.
Bevezettük az SQL 2014 számosságbecslőt CardinalityEstimationModelVersion="120"	További számosságbecslési (CE) fejlesztések a számosságbecslési modell 130-nal, amely egy lekérdezési tervből látható. CardinalityEstimationModelVersion="130"
Batch mód és sormód változása oszlopcentrikus indexekkel: Az oszlopcentrikus indexet tartalmazó táblák rendezése sor módban van Az ablakfüggvény-aggregátumok sor módban működnek, például LAGLEAD Több különböző záradékot tartalmazó oszloptártáblák lekérdezései Sor módban A MAXDOP 1 vagy sor módban végrehajtott soros tervvel futó lekérdezések	Batch mód és sormód változása oszlopcentrikus indexekkel: Az oszlopcentrikus indexet tartalmazó táblák rendezései mostantól kötegelt módban vannak Az ablakos aggregátumok mostantól kötegelt módban működnek, például LAGLEAD A Több különböző záradékot tartalmazó oszlopcentrikus táblák lekérdezései Batch módban működnek A MAXDOP 1 vagy soros tervvel futó lekérdezések Batch módban futnak
A statisztikák automatikusan frissíthetők.	A statisztikákat automatikusan módosító logika agresszívabb a nagy táblákon. A gyakorlatban ez csökkenti azokat az eseteket, amikor az ügyfelek teljesítményproblémákat tapasztaltak olyan lekérdezésekben, amelyekben az újonnan beszúrt sorokat gyakran kérdezik le, de a statisztikákat nem frissítették, hogy belefoglalják ezeket az értékeket.
A Trace 2371 alapértelmezés szerint ki van kapcsolva az SQL Server 2014-ben (12.x).	A Trace 2371 alapértelmezés szerint be van kapcsolva az SQL Server 2016-ban (13.x). A nyomkövetési jelző 2371 azt jelzi az automatikus statisztika-frissítőnek, hogy a sorok egy kisebb, de annál bölcsebb részhalmazát mintázzon egy olyan táblában, amely sok sort tartalmaz. Az egyik fejlesztés az, hogy a mintába belefoglalja a legutóbb beszúrt sorokat. Egy másik fejlesztés, hogy a lekérdezések a frissítési statisztikai folyamat futtatása közben is futnak, ahelyett, hogy letiltanák a lekérdezést.
A 120. szint esetében a statisztikákat egyszálas folyamat mintavételezi.	A 130. szint esetében a statisztikákat egy többszálú folyamat (párhuzamos folyamat) mintázza.
A korlát 253 bejövő idegen kulcs.	Egy adott táblára legfeljebb 10 000 bejövő idegen kulcs vagy hasonló hivatkozás hivatkozhat. A korlátozásokról további információt az idegenkulcs-kapcsolatok létrehozása című témakörben talál.
Az elavult MD2, MD4, MD5, SHA és SHA1 kivonatoló algoritmusok engedélyezettek.	Csak SHA2_256 és SHA2_512 kivonatoló algoritmusok engedélyezettek.
	Az SQL Server 2016 (13.x) néhány adattípus-átalakítás és néhány (többnyire nem gyakori) művelet fejlesztéseit tartalmazza. További részletekért tekintse meg az SQL Server és az Azure SQL Database egyes adattípusokkal és nem gyakori műveletekkel kapcsolatos fejlesztéseit.
A STRING_SPLIT függvény nem érhető el.	A STRING_SPLIT függvény a 130-es vagy újabb kompatibilitási szinten érhető el. Ha az adatbázis kompatibilitási szintje 130-nál alacsonyabb, az SQL Server nem fogja tudni megtalálni és végrehajtani STRING_SPLIT a függvényt.

Az SQL Server 2016 (13.x) előtti SQL Server korábbi verzióiban a 4199-ben nyomkövetési jelző alatt lévő javítások alapértelmezés szerint engedélyezve vannak. A kompatibilitási mód 130. A nyomkövetési jelző 4199 továbbra is alkalmazható az SQL Server 2016 (13.x) után kiadott új lekérdezésoptimalizáló-javításokra. A régebbi lekérdezésoptimalizáló SQL Database-ben való használatához a 110-es kompatibilitási szintet kell választania. A Nyomkövetési jelző 4199-ről további információt a 4199-ben található nyomkövetési jelzőben talál.

Az alacsonyabb kompatibilitási szintek és a 120-es szint közötti különbségek

Ez a szakasz a 120-es kompatibilitási szinttel bevezetett új viselkedéseket ismerteti.

110-es vagy alacsonyabb kompatibilitási szint beállítása	120 kompatibilitási szint beállítása
A rendszer a régebbi lekérdezésoptimalizálót használja.	Az SQL Server 2014 (12.x) jelentős fejlesztéseket tartalmaz a lekérdezésterveket létrehozó és optimalizáló összetevőn. Ez az új lekérdezésoptimalizáló funkció a 120-es adatbázis-kompatibilitási szinttől függ. Az új adatbázis-alkalmazásokat a 120-es adatbáziskompatibilitási szinttel kell fejleszteni, hogy kihasználhassák ezeket a fejlesztéseket. Az SQL Server korábbi verzióiból áttelepített alkalmazásokat gondosan tesztelni kell, hogy a jó teljesítmény megmaradjon vagy javuljon. Ha a teljesítmény csökken, az adatbázis kompatibilitási szintjét 110-es vagy korábbi értékre állíthatja a régebbi lekérdezésoptimalizáló módszertan használatához. A 120-es adatbázis-kompatibilitási szint egy új számosságbecslőt használ, amely a modern adattárházakhoz és az OLTP-számítási feladatokhoz van hangolva. Mielőtt teljesítményproblémák miatt 110-esre állítja az adatbázis kompatibilitási szintjét, tekintse meg az SQL Server 2016 újdonságainakLekérdezéstervek szakaszában található javaslatokat.
A 120-nál alacsonyabb kompatibilitási szinteken a rendszer figyelmen kívül hagyja a nyelvi beállítást a dátumérték sztringértékké alakításakor. Ez a viselkedés csak a dátumtípusra jellemző. Lásd a B példát a Példák szakaszban.	A nyelvi beállítás nem lesz figyelmen kívül hagyva a dátumérték sztringértékké alakításakor.
A záradék jobb oldalán EXCEPT található rekurzív hivatkozások végtelen hurkot hoznak létre. A Példák szakaszban található C példa ezt a viselkedést mutatja be.	A záradék rekurzív hivatkozásai EXCEPT hibát okoznak az ANSI SQL-szabványnak megfelelően.
A rekurzív gyakori táblakifejezés (CTE) lehetővé teszi az ismétlődő oszlopneveket.	A rekurzív CTE nem engedélyezi az ismétlődő oszlopneveket.
A letiltott eseményindítók akkor lesznek engedélyezve, ha az eseményindítók módosulnak.	Az eseményindító módosítása nem módosítja az eseményindító állapotát (engedélyezve vagy letiltva).
A OUTPUT INTO tábla záradék figyelmen kívül hagyja az IDENTITY_INSERT SETTING = OFF explicit értékeket, és lehetővé teszi az explicit értékek beszúrását.	Ha ki van állítva, nem szúrhat be explicit értékeket egy tábla IDENTITY_INSERT identitásoszlopához.
Ha az adatbázis-elszigetelés részlegesre van állítva, az $action utasítás záradékában OUTPUT szereplő MERGE mező érvényesítése rendezési hibát eredményezhet.	Az utasítás záradéka $action által MERGE visszaadott értékek rendezése a kiszolgáló rendezése helyett az adatbázis-rendezés, és a rendszer nem ad vissza rendezési ütközési hibát.
Az SELECT INTO utasítás mindig egyszálas beszúrási műveletet hoz létre.	Egy SELECT INTO utasítás párhuzamos beszúrási műveletet hozhat létre. Nagy számú sor beszúrása esetén a párhuzamos művelet javíthatja a teljesítményt.

Az alacsonyabb kompatibilitási szintek és a 100 és 110 közötti különbségek

Ez a szakasz a 110-es kompatibilitási szinttel bevezetett új viselkedéseket ismerteti. Ez a szakasz a 110 feletti kompatibilitási szintekre is vonatkozik.

Kompatibilitási szint beállítása 100 vagy annál alacsonyabb	Legalább 110 kompatibilitási szint beállítása
A közös nyelvi futtatókörnyezeti (CLR) adatbázis-objektumok a CLR 4-es verziójával lesznek végrehajtva. A CLR 4-es verziójában bevezetett viselkedésváltozások azonban elkerülhetők. További információ: A CLR-integráció újdonságai?	A CLR-adatbázis-objektumok végrehajtása a CLR 4-es verziójával történik.
Az XQuery függvények sztringhosszúságú és részstring számlálják meg az egyes helyettesítő karaktereket két karakterként.	Az XQuery függvények sztringhosszúságú és részstring számlálják meg az egyes helyettesítő karaktereket egy karakterként.
PIVOT egy rekurzív közös táblakifejezés (CTE) lekérdezésben engedélyezett. A lekérdezés azonban helytelen eredményeket ad vissza, ha csoportosításonként több sor is van.	PIVOT nem engedélyezett rekurzív közös táblakifejezési (CTE) lekérdezésekben. A függvény hibát ad vissza.
Az RC4 algoritmus csak a visszamenőleges kompatibilitás érdekében támogatott. Az új anyagok csak RC4 vagy RC4_128 használatával titkosíthatók, ha az adatbázis kompatibilitási szintje 90 vagy 100. (Nem ajánlott.) Az SQL Server 2012 -ben (11.x) az RC4 vagy RC4_128 használatával titkosított anyagok bármilyen kompatibilitási szinten visszafejthetők.	Az új anyagok nem titkosíthatók RC4 vagy RC4_128 használatával. Használjon helyette egy újabb algoritmust, például az egyik AES-algoritmust. Az SQL Server 2012 -ben (11.x) az RC4 vagy RC4_128 használatával titkosított anyagok bármilyen kompatibilitási szinten visszafejthetők.
Az CAST- és CONVERT adattípusok alapértelmezett stílusa és műveletei 121, kivéve, ha valamelyik típust egy számított oszlopkifejezésben használják. Számított oszlopok esetén az alapértelmezett stílus a 0. Ez a viselkedés hatással van a számított oszlopokra, amikor létrejönnek, automatikus paraméterezést igénylő lekérdezésekben vagy kényszerdefiníciókban használják őket. A Példák szakaszban a D példa a 0 és a 121 stílus közötti különbséget mutatja be. Nem mutatja be a fent leírt viselkedést. A dátum - és időstílusokról a CAST és a CONVERT című témakörben talál további információt.	A 110-es kompatibilitási szinten az CAST- és CONVERT adattípusok alapértelmezett stílusa és műveletei mindig 121. Ha a lekérdezés a régi viselkedésre támaszkodik, használjon 110-nél kisebb kompatibilitási szintet, vagy explicit módon adja meg az érintett lekérdezés 0 stílusát. Az adatbázis 110-es kompatibilitási szintre való frissítése nem módosítja a lemezre tárolt felhasználói adatokat. Ezeket az adatokat szükség szerint manuálisan kell kijavítania. Ha például olyan forrásból hozott SELECT INTO létre táblázatot, amely a fent leírt számított oszlopkifejezést tartalmazta, az adatokat (a 0. stílus használatával) a rendszer tárolja, és nem magát a számított oszlopdefiníciót. Ezeket az adatokat manuálisan kell frissítenie, hogy megfeleljen a 121-nek.
A + (Hozzáadás) operátor akkor alkalmazható dátum, idő, datetime2 vagy datetimeoffset típusú operandusra, ha a másik operandus dátum/idő típusú vagy smalldatetime típusú.	Ha a hozzáadási operátort dátum, idő, datetime2 vagy datetimeoffset típusú operandusra próbálja alkalmazni, és egy datetime vagy smalldatetime típusú operandus 402-es hibát fog okozni.
A particionált nézetben hivatkozott smalldatetime típusú távoli táblák oszlopai dátumidőként vannak leképezve. A helyi táblák megfelelő oszlopainak (a kijelölési listában ugyanabban a sorrendben) dátum/idő típusúnak kell lenniük.	A particionált nézetben hivatkozott , smalldatetime típusú távoli táblák oszlopai kisdátumidőként vannak leképezve. A helyi táblák megfelelő oszlopainak (a kijelölési listában azonos sorrendben) kisdátum típusúnak kell lenniük. A 110-es verzióra való frissítés után az elosztott particionált nézet az adattípus eltérése miatt meghiúsul. Ezt úgy oldhatja meg, hogy a távoli tábla adattípusát dátumidőre módosítja, vagy a helyi adatbázis kompatibilitási szintjét 100-ra vagy annál alacsonyabbra állítja.
SOUNDEX függvény a következő szabályokat valósítja meg: 1) A nagybetűs H vagy a nagybetűs W figyelmen kívül lesz hagyva, amikor két olyan mássalhangzót választ el, amelyek azonos számmal rendelkeznek a SOUNDEX kódban. 2) Ha a character_expression első két karaktere ugyanazzal a számmal rendelkezik a SOUNDEX kódban, mindkét karakter szerepel. Máskülönben, ha egy egymás melletti mássalhangzónak ugyanaz a száma a SOUNDEX kódban, az első kivételével mindegyik ki lesz zárva.	SOUNDEX függvény a következő szabályokat valósítja meg: 1) Ha a nagybetűs H vagy a nagybetűs W két olyan mássalhangzót választ el, amelyek azonos számmal rendelkeznek a SOUNDEX kódban, a jobb oldali mássalhangzó figyelmen kívül lesz hagyva 2) Ha az egymás melletti mássalhangzók egy halmaza ugyanazzal a számmal rendelkezik a SOUNDEX kódban, az első kivételével mindegyik ki van zárva. A további szabályok miatt a függvény által SOUNDEX kiszámított értékek eltérhetnek a korábbi kompatibilitási szinteken kiszámított értékekétől. A 110-es kompatibilitási szintre való frissítés után előfordulhat, hogy újra kell építenie a függvényt használó SOUNDEX indexeket, halmokat vagy CHECK korlátozásokat. További információ: SOUNDEX.
a /> nem érhető el.	STRING_AGG választható <order_clause>. További információ: STRING_AGG

A kompatibilitási szint és a 100-es szint közötti különbségek

Ez a szakasz a 100-es kompatibilitási szinttel bevezetett új viselkedéseket ismerteti.

90 kompatibilitási szint beállítása	100 kompatibilitási szint beállítása	Hatás lehetősége
A QUOTED_IDENTIFIER beállítás mindig ON értékre van állítva a többértékű táblaértékű függvényekhez, amikor azok a munkamenet-szint beállításától függetlenül jönnek létre.	Az IDÉZŐJELes azonosító munkamenet-beállítás a többértékű táblaértékű függvények létrehozásakor teljesül.	Közepes
Partíciófüggvény létrehozásakor vagy módosításakor a függvény datetime és smalldatetime literáljai kiértékelése US_English nyelvi beállításként történik.	Az aktuális nyelvi beállítás a datetime és a smalldatetime literálok kiértékelésére szolgál a partíciófüggvényben.	Közepes
A FOR BROWSE záradék engedélyezett (és figyelmen kívül hagyható) az és INSERT az utasításokbanSELECT INTO.	A FOR BROWSE záradék nem engedélyezett, INSERT és SELECT INTO az utasítások sem.	Közepes
A záradékban OUTPUT teljes szöveges predikátumok használhatók.	A záradék nem engedélyezi a OUTPUT teljes szöveges predikátumok használatát.	Alacsony
CREATE FULLTEXT STOPLIST, ALTER FULLTEXT STOPLISTés DROP FULLTEXT STOPLIST nem támogatottak. A rendszer leállítása automatikusan új teljes szöveges indexekhez van társítva.	CREATE FULLTEXT STOPLIST, ALTER FULLTEXT STOPLISTés DROP FULLTEXT STOPLIST támogatottak.	Alacsony
MERGE nem fenntartott kulcsszóként van kényszerítve.	A MERGE egy teljesen fenntartott kulcsszó. Az MERGE utasítás 100 és 90 kompatibilitási szinten is támogatott.	Alacsony
<dml_table_source> Az INSERT utasítás argumentumának használata szintaxishibát okoz.	Egy OUTPUT záradék eredményeit rögzítheti beágyazott INSERT, UPDATE, DELETE vagy MERGE utasításban, és beszúrhatja ezeket az eredményeket egy céltáblába vagy nézetbe. Ez az <dml_table_source> INSERT utasítás argumentumával történik.	Alacsony
Ha nincs NOINDEX megadva, DBCC CHECKDB vagy DBCC CHECKTABLE fizikai és logikai konzisztenciát is ellenőriz egyetlen táblán vagy indexelt nézetben, valamint az összes nem rendezett és XML-indexen. A térbeli indexek nem támogatottak.	Ha nincs NOINDEX megadva, DBCC CHECKDB vagy DBCC CHECKTABLE fizikai és logikai konzisztenciát is ellenőriz egyetlen táblán és annak nemclustered indexén. XML-indexek, térbeli indexek és indexelt nézetek esetén azonban alapértelmezés szerint csak a fizikai konzisztencia-ellenőrzéseket hajtja végre a rendszer. Ha WITH EXTENDED_LOGICAL_CHECKS meg van adva, a logikai ellenőrzések az indexelt nézeteken, XML-indexeken és térbeli indexeken történnek, ahol vannak. Alapértelmezés szerint a fizikai konzisztencia-ellenőrzéseket a logikai konzisztencia ellenőrzése előtt hajtja végre a rendszer. Ha NOINDEX is meg van adva, csak a logikai ellenőrzések lesznek végrehajtva.	Alacsony
Ha egy OUTPUT záradékot használ egy adatmanipulációs nyelv (DML) utasítással, és futásidejű hiba történik az utasítás végrehajtása során, a teljes tranzakció leáll, és vissza lesz állítva.	Amikor egy záradékot OUTPUT használ egy adatmanipulációs nyelv (DML) utasítással, és futásidejű hiba történik az utasítás végrehajtása során, a viselkedés a SET XACT_ABORT beállítástól függ. Ha SET XACT_ABORT ki van kapcsolva, a záradékot használó OUTPUT DML-utasítás által generált utasítás megszakítja az utasítást, de a köteg végrehajtása folytatódik, és a tranzakció nem kerül vissza. Ha SET XACT_ABORT be van kapcsolva, a DML utasítás által az OUTPUT záradékkal létrehozott összes futásidejű hiba leállítja a köteget, és a tranzakció vissza lesz állítva.	Alacsony
A KOCKA és a ROLLUP nem fenntartott kulcsszavakként lesz érvényesítve.	CUBE és ROLLUP a GROUP BY záradékban foglalt kulcsszavak.	Alacsony
A rendszer szigorú ellenőrzést alkalmaz az XML anyType típusú elemeire.	A rendszer a hasadt érvényesítést alkalmazza az anyType típusú elemekre. További információkért lásd a helyettesítő karakterek összetevőit és a tartalomérvényesítést.	Alacsony
Az xsi:nil és az xsi:type speciális attribútumok nem kérdezhetők le és nem módosíthatók adatkezelési nyelvi utasításokkal. Ez azt jelenti, hogy ez /e/@xsi:nil meghiúsul, miközben /e/@* figyelmen kívül hagyja az xsi:nil és az xsi:type attribútumokat. /e Az xsi:nil és az xsi:type attribútumokat azonban visszaadja a konzisztenciáhozSELECT xmlCol, még akkor is, ha xsi:nil = "false".	Az xsi:nil és az xsi:type speciális attribútumok normál attribútumként vannak tárolva, és lekérdezhetők és módosíthatók. A lekérdezés SELECT x.query('a/b/@*') végrehajtása például az összes attribútumot visszaadja, beleértve az xsi:nil és az xsi:type értéket. Ha ki szeretné zárni ezeket a típusokat a lekérdezésben, cserélje le @* az @*[namespace-uri(.) != " beszúrására", és ne vagy (local-name(.) = "type".local-name(.) ="nil"	Alacsony
A felhasználó által definiált függvény, amely egy XML-konstans sztringértékét SQL Server-dátum/idő típusúvá alakítja, determinisztikusként van megjelölve.	A felhasználó által definiált függvény, amely egy XML-állandó sztringértékét SQL Server-dátum/idő típusúvá alakítja, nem determinisztikusként van megjelölve.	Alacsony
Az XML-egyesítés és a listatípusok nem támogatottak teljes mértékben.	Az egyesítő és listatípusok teljes mértékben támogatottak, beleértve a következő funkciókat: Lista egyesítő elemei Unió Atomtípusok listája Az egyesítők listája	Alacsony
Az xQuery metódushoz szükséges SET beállítások nem lesznek érvényesítve, ha a metódus egy nézetben vagy beágyazott táblaértékű függvényben található.	Az xQuery metódushoz szükséges SET-beállítások akkor lesznek érvényesítve, ha a metódus egy nézetben vagy beágyazott táblaértékű függvényben található. Hiba merül fel, ha a metódus SET beállításai helytelenül vannak beállítva.	Alacsony
A sorvégi karaktereket (kocsivissza és sorcsatorna) tartalmazó XML-attribútumértékek nem normalizálva lesznek az XML-szabványnak megfelelően. Vagyis a rendszer mindkét karaktert visszaadja egyetlen sorbetöltési karakter helyett.	A sorvégi karaktereket (kocsivissza és sorcsatorna) tartalmazó XML-attribútumértékek az XML-szabványnak megfelelően normalizálódnak. Ez azt jelzi, hogy a külső elemzésű entitások (beleértve a dokumentumentitást is) minden sortörése normalizálva lesz a bemenetkor a két karakterből álló sorozat #xD #xA és minden olyan #xD lefordításával, amelyet nem követ egyetlen #xA karakterre #xA. Azok az alkalmazások, amelyek attribútumokat használnak a sorvégi karaktereket tartalmazó sztringértékek átviteléhez, nem kapják vissza ezeket a karaktereket a beküldéskor. A normalizálási folyamat elkerülése érdekében az XML numerikus karakterentitások használatával kódolhatja az összes sorvég karaktert.	Alacsony
Az oszlop tulajdonságai ROWGUIDCOL , és IDENTITY helytelenül nevezhetők el kényszerként. Végrehajtja például az utasítást CREATE TABLE T (C1 int CONSTRAINT MyConstraint IDENTITY) , de a kényszer neve nem marad meg, és nem érhető el a felhasználó számára.	Az oszlop tulajdonságai ROWGUIDCOL , és IDENTITY nem nevezhetők el kényszerként. A függvény a 156-os hibát adja vissza.	Alacsony
Az oszlopok kétirányú hozzárendeléssel UPDATE T1 SET @v = column_name = <expression> történő frissítése váratlan eredményeket eredményezhet, mivel a változó élő értéke más záradékokban, például az WHEREON utasítás végrehajtása során, az utasítás kezdőértéke helyett használható. Ez azt eredményezheti, hogy a predikátumok jelentése soronként kiszámíthatatlanul változik. Ez a viselkedés csak akkor alkalmazható, ha a kompatibilitási szint értéke 90.	Az oszlopok kétirányú hozzárendeléssel történő frissítése várt eredményeket eredményez, mert az utasítás végrehajtása során csak az oszlop utasítás kezdőértéke érhető el.	Alacsony
A változó-hozzárendelés engedélyezett egy legfelső szintű UNION operátort tartalmazó utasításban, de váratlan eredményeket ad vissza. További információ az E példában.	A változók hozzárendelése nem engedélyezett egy legfelső szintű UNION operátort tartalmazó utasításban. A függvény az 10734-et adja vissza. Keressen egy javasolt átírást az E példában.	Alacsony
A(z) {fn CONVERT()} ODBC függvény a nyelv alapértelmezett dátumformátumát használja. Egyes nyelvek esetében az alapértelmezett formátum az YDM, amely konvertálási hibákat okozhat, ha a KONVERTÁLÁS() más függvényekkel van kombinálva, például {fn CURDATE()}YMD-formátumot vár.	Az ODBC függvény {fn CONVERT()} a 121. stílust (nyelvfüggetlen YMD-formátumot) használja az ODBC-adattípusokra való konvertáláskor, SQL_TIMESTAMP, SQL_DATE, SQL_TIME, SQLDATE, SQL_TYPE_TIME és SQL_TYPE_TIMESTAMP.	Alacsony
A datetime-intrinsics például DATEPART nem követeli meg, hogy a sztring bemeneti értékei érvényes dátum/idő literálok legyenek. A fordítás például SELECT DATEPART (year, '2007/05-30') sikeresen megtörtént.	A datetime-intrinsics például DATEPART megköveteli, hogy a sztring bemeneti értékei érvényes datetime literálok legyenek. Érvénytelen datetime literál használatakor a rendszer a 241-et adja vissza.	Alacsony
A CSERE függvény első bemeneti paraméterében megadott záró szóközöket a rendszer levágja, ha a paraméter karakter típusú. Az utasításban SELECT '<' + REPLACE(CONVERT(char(6), 'ABC '), ' ', 'L') + '>'például az érték 'ABC ' helytelenül lesz kiértékelve 'ABC'.	A záró szóközök mindig megmaradnak. A függvény előző viselkedésére támaszkodó alkalmazások esetében használja a RTRIM függvényt a függvény első bemeneti paraméterének megadásakor. A következő szintaxis például az SQL Server 2005 viselkedését fogja reprodukálni: SELECT '<' + REPLACE(RTRIM(CONVERT(char(6), 'ABC ')), ' ', 'L') + '>'.	Alacsony

Fenntartott kulcsszavak

A kompatibilitási beállítás az adatbázismotor által fenntartott kulcsszavakat is meghatározza. Az alábbi táblázat az egyes kompatibilitási szintek által bevezetett fenntartott kulcsszavakat mutatja be.

Kompatibilitási szint beállítása	Fenntartott kulcsszavak
130	Meg kell határozni.
120	Nincs.
110	WITHIN GROUP, TRY_CONVERT, SEMANTICKEYPHRASETABLE, SEMANTICSIMILARITYDETAILSTABLESEMANTICSIMILARITYTABLE
100	\, \, \
90	EXTERNAL, PIVOT, UNPIVOT, REVERTTABLESAMPLE

Egy adott kompatibilitási szinten a fenntartott kulcsszavak tartalmazzák az adott szinten vagy alatt bevezetett összes kulcsszót. Így például a 110- es szintű alkalmazások esetében az előző táblázatban felsorolt összes kulcsszó foglalt. Az alacsonyabb kompatibilitási szinteken a 100-es szintű kulcsszavak továbbra is érvényesek maradnak az objektumnevekben, de az ezeknek a kulcsszavaknak megfelelő 110-es szintű nyelvi funkciók nem érhetők el.

A bevezetés után egy kulcsszó fenntartott marad. A 90-es kompatibilitási szinten bevezetett fenntartott PIVOT kulcsszó például a 100-es, a 110-es és a 120-es szinten is fenntartott.

Ha egy alkalmazás olyan azonosítót használ, amely a kompatibilitási szintje szempontjából kulcsszóként van fenntartva, az alkalmazás sikertelen lesz. Ennek megkerüléséhez csatolja az azonosítót szögletes zárójelek ([]) vagy idézőjelek ("" között); Ha például egy olyan alkalmazást szeretne frissíteni, amely az azonosítót EXTERNAL használja a 90-es kompatibilitási szintre, módosíthatja az azonosítót vagy [EXTERNAL]"EXTERNAL"a .

További információ: Fenntartott kulcsszavak.

Engedélyek

Az adatbázishoz ALTER engedély szükséges.

Példák

Egy. A kompatibilitási szint módosítása

Az alábbi példa a AdventureWorks2022 kompatibilitási szintjét 150-esre módosítja, amely az SQL Server 2019 alapértelmezett értéke (15.x).

ALTER DATABASE AdventureWorks2022
SET COMPATIBILITY_LEVEL = 150;
GO

Az alábbi példa az aktuális adatbázis kompatibilitási szintjét adja vissza.

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

B. A SET LANGUAGE utasítás figyelmen kívül hagyása a 120-es vagy újabb kompatibilitási szint kivételével

Az alábbi lekérdezés figyelmen kívül hagyja az utasítást, kivéve a SET LANGUAGE 120-es vagy újabb kompatibilitási szintet.

SET DATEFORMAT dmy;

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

SET LANGUAGE dutch;

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

120-nál kisebb kompatibilitási szint esetén az eredmények: 12 May 2011

A kompatibilitási szint 120-ra vagy annál magasabbra történő beállítása esetén az eredmények: 12 mei 2011

C. 110-es vagy alacsonyabb kompatibilitási szintű beállítás esetén a EXCEPT záradék jobb oldalán rekurzív hivatkozások végtelen hurkot hoznak létre

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. A 0 és 121 stílus közötti különbség

Ha a kompatibilitási szint kisebb, mint 110, az CAST és CONVERT adattípusok alapértelmezett stílusa és műveletei 121, kivéve, ha bármelyik típust használják egy számított oszlopkifejezésben. Számított oszlopok esetén az alapértelmezett stílus a 0.

Ha a kompatibilitási szint 110 vagy magasabb, az CAST- és CONVERT adattípusok alapértelmezett stílusa és műveletei mindig 121. További információt az alacsonyabb kompatibilitási szintek és a 100 és 110 közötti különbségek című témakörben talál.

A dátum- és időstílusokról a CAST és a CONVERT című témakörben talál további információt.

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

Ez a következő eredményekhez hasonló eredményeket ad vissza:

TimeStyle0	TimeStyle121	Datetime2Style0	Datetime2Style121
15:15	15:15:35.8100000	2011. jún. 7. 15:15	2011-06-07 15:15:35.8130000

E. Változó-hozzárendelés – felső szintű UNION operátor

A 90-es adatbáziskompatibilitási szint beállítása alatt a változó-hozzárendelés engedélyezett egy legfelső szintű UNION operátort tartalmazó utasításban, de váratlan eredményeket ad vissza. Az alábbi utasításokban például a helyi változó @v az oszlop BusinessEntityID értékét rendeli hozzá két tábla egyesítéséből. Definíció szerint, ha a SELECT utasítás egynél több értéket ad vissza, a változó az utolsó visszaadott értékhez lesz hozzárendelve. Ebben az esetben a változóhoz helyesen rendeli hozzá az utolsó értéket, de a SELECT UNION utasítás eredményhalmazát is visszaadja a rendszer.

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;

A 100-as vagy újabb adatbáziskompatibilitási szint beállítása alatt a változó-hozzárendelés nem engedélyezett egy legfelső szintű UNION operátort tartalmazó utasításban. A függvény az 10734-et adja vissza.

A hiba megoldásához írja át újra a lekérdezést az alábbi példában látható módon.

DECLARE @v AS INT;

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

SELECT @v;

Kapcsolódó tartalom

• A teljesítmény stabilitásának megőrzése az újabb SQL Serverre való frissítés során
• Az adatbázis kompatibilitási szintjének módosítása és a Lekérdezéstár használata
• Kompatibilitási tanúsítvány
• ALTER DATABASE (Transact-SQL)
• Adatbázisok frissítése a Lekérdezéshangolási segéd használatával
• ADATBÁZIS LÉTREHOZÁSA
• Adatbázis kompatibilitási szintjének megtekintése vagy módosítása
• Lekérdezéstári tippek