ÄNDRA DATABAS (Transact-SQL) kompatibilitetsnivå

Gäller för:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

Anger Transact-SQL och frågebearbetningsbeteenden som ska vara kompatibla med den angivna versionen av SQL-motorn. Andra alternativ för ALTER DATABASE finns i ALTER DATABASE.

Mer information om syntaxkonventionerna finns i Transact-SQL syntaxkonventioner.

Syntax

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

Argumentpunkter

database_name

Namnet på databasen som ska ändras.

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

Den version av SQL Server som databasen ska göras kompatibel med. Följande kompatibilitetsnivåvärden kan konfigureras (alla versioner stöder inte alla ovan angivna kompatibilitetsnivå):

Produkt	Databasmotorversion	Standardbeteckning för kompatibilitetsnivå	Värden på kompatibilitetsnivå som stöds
Azure SQL Database	17	170	170, 160, 150, 140, 130, 120, 110, 100
Hanterad instans i Azure SQL	16	150	160, 150, 140, 130, 120, 110, 100
Förhandsversion av SQL Server 2025 (17.x)	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)	tretton	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

Viktigt!

Databasmotorns versionsnummer för SQL Server och Azure SQL Database är inte jämförbara med varandra och är snarare interna versionsnummer för dessa separata produkter. Databasmotorn för Azure SQL Database baseras på samma kodbas som SQL Server-databasmotorn. Det viktigaste är att databasmotorn i Azure SQL Database alltid har de senaste SQL-databasmotorbitarna. Version 12 av Azure SQL Database är nyare än version 15 av SQL Server.

Metodtips för att uppgradera databaskompatibilitetsnivå

Det rekommenderade arbetsflödet för uppgradering av kompatibilitetsnivån finns i Behåll prestandastabilitet under uppgraderingen till nyare SQL Server. Mer information om hur du uppgraderar databasens kompatibilitetsnivå finns i Uppgradera databaser med hjälp av Frågejusteringsassistenten.

Anmärkningar

För alla installationer av SQL Server är standardkompatibilitetsnivån associerad med versionen av databasmotorn. Nya databaser är inställda på den här nivån om inte model databasen har en lägre kompatibilitetsnivå. För databaser som är anslutna eller återställde från en tidigare version av SQL Server behåller databasen sin befintliga kompatibilitetsnivå, om den är minst tillåten för den instansen av SQL Server. Om du flyttar en databas med en kompatibilitetsnivå som är lägre än den tillåtna nivån av databasmotorn ställs databasen automatiskt in på den lägsta tillåtna kompatibilitetsnivån. Detta gäller både system- och användardatabaser.

Följande beteenden förväntas för SQL Server 2017 (14.x) när en databas är ansluten eller återställd och efter en uppgradering på plats:

• Om kompatibilitetsnivån för en användardatabas var 100 eller högre före uppgraderingen förblir den densamma efter uppgraderingen.
• Om kompatibilitetsnivån för en användardatabas var 90 före uppgraderingen anges kompatibilitetsnivån i den uppgraderade databasen till 100, vilket är den lägsta kompatibilitetsnivån som stöds i SQL Server 2017 (14.x).
• Kompatibilitetsnivåerna för tempdbdatabaserna , model, msdb, och Resurs är inställda på standardkompatibilitetsnivån för en viss databasmotorversion.
• Systemdatabasen master behåller den kompatibilitetsnivå som den hade före uppgraderingen. Detta påverkar inte användardatabasens beteende.

För befintliga databaser som körs på lägre kompatibilitetsnivåer, så länge programmet inte behöver använda förbättringar som endast är tillgängliga på en högre databaskompatibilitetsnivå, är det en giltig metod för att upprätthålla den tidigare databaskompatibilitetsnivån. För nytt utvecklingsarbete, eller när ett befintligt program kräver användning av nya funktioner, till exempel Intelligent frågebearbetning i SQL-databaser och några nya Transact-SQL, planerar du att uppgradera databasens kompatibilitetsnivå till den senaste tillgängliga. Mer information finns i Kompatibilitetsnivåer och Uppgraderingar av databasmotorn.

Anmärkning

Om det inte finns några användarobjekt och beroenden är det i allmänhet säkert att uppgradera till standardkompatibilitetsnivån. Mer information finns i Rekommendationer – huvuddatabas.

Använd ALTER DATABASE för att ändra databasens kompatibilitetsnivå. Den nya kompatibilitetsnivåinställningen för en databas börjar gälla när ett USE <database> kommando utfärdas eller en ny inloggning bearbetas med databasen som standarddatabaskontext.

Om du vill visa den aktuella kompatibilitetsnivån för en databas frågar du compatibility_level kolumnen i katalogvyn sys.databases .

En distributionsdatabas som skapades i en tidigare version av SQL Server och uppgraderas till SQL Server 2016 (13.x) RTM eller Service Pack 1 har en kompatibilitetsnivå på 90, vilket inte stöds för andra databaser. Detta påverkar inte replikeringsfunktionen. Om du uppgraderar till senare servicepaket och versioner av SQL Server kommer kompatibilitetsnivån för distributionsdatabasen att ökas så att den master matchar databasens.

Om du vill använda databaskompatibilitetsnivå 120 eller senare för en databas överlag, men anmäl dig till kardinalitetsuppskattningsmodellen för SQL Server 2012 (11.x), som mappar till databaskompatibilitetsnivå 110, se ALTER DATABASE SCOPED CONFIGURATION, och i synnerhet dess nyckelord LEGACY_CARDINALITY_ESTIMATION = ON.

Kommentarer för Azure SQL

Standardkompatibilitetsnivån är 170 för nyligen skapade databaser i Azure SQL Database och SQL Database i Microsoft Fabric.

Standardkompatibilitetsnivån är 150 för nyligen skapade databaser i SQL Server 2022-uppdateringsprincipen för Azure SQL Managed Instance-erbjudandet.

Standardkompatibilitetsnivån är 170 för nyligen skapade databaser i uppdateringsprincipen Always-up-to-date i Azure SQL Managed Instance-erbjudandet.

Microsoft uppdaterar inte databaskompatibilitetsnivån automatiskt för befintliga databaser. Det är upp till kunderna att göra efter eget gottfinnande.

Microsoft rekommenderar starkt att kunderna planerar att uppgradera till den senaste kompatibilitetsnivån för att kunna använda de senaste förbättringarna av frågeoptimeringen. Tips om hur du utvärderar prestandaskillnaderna för dina viktigaste frågor mellan två olika kompatibilitetsnivåer i Azure SQL Database finns i Förbättrad frågeprestanda med kompatibilitetsnivå 130 i Azure SQL Database. Den här artikeln refererar till kompatibilitetsnivå 130 och SQL Server, men samma metod gäller för uppgraderingar till 140 eller högre nivåer i SQL Server och Azure SQL Database.

Alla funktioner som varierar beroende på kompatibilitetsnivå stöds inte i Azure SQL Database.

Hitta aktuell kompatibilitetsnivå

Om du vill fastställa den aktuella kompatibilitetsnivån frågar du kolumnen compatibility_levelsys.databases.

SELECT [name],
       compatibility_level
FROM sys.databases;

Kör följande fråga för att fastställa vilken version av databasmotorn du är ansluten till.

SELECT SERVERPROPERTY('ProductVersion');

Kompatibilitetsnivåer och uppgraderingar av databasmotorn

Databaskompatibilitetsnivå är ett värdefullt verktyg för att hjälpa till med databasmodernisering genom att låta SQL Server Database Engine uppgraderas samtidigt som samma funktionsstatus bibehålls för anslutning av program genom att upprätthålla samma databaskompatibilitetsnivå före uppgraderingen. Det innebär att det går att uppgradera från en äldre version av SQL Server (till exempel SQL Server 2008 (10.0.x)) till SQL Server eller Azure SQL Database (inklusive Azure SQL Managed Instance) utan programändringar (förutom databasanslutning). Mer information finns i Kompatibilitetscertifiering.

Så länge programmet inte behöver använda förbättringar som bara är tillgängliga på en högre databaskompatibilitetsnivå är det en giltig metod för att uppgradera SQL Server Database Engine och upprätthålla den tidigare databaskompatibilitetsnivån. Mer information om hur du använder kompatibilitetsnivå för bakåtkompatibilitet finns i Kompatibilitetscertifiering.

Kompatibilitetsnivåer och lagrade procedurer

När en lagrad procedur körs använder den den aktuella kompatibilitetsnivån för databasen där den definieras. När kompatibilitetsinställningen för en databas ändras, omkompileras alla dess lagrade procedurer automatiskt.

Använd kompatibilitetsnivå för bakåtkompatibilitet

Inställningen för databaskompatibilitetsnivå ger bakåtkompatibilitet med tidigare versioner av SQL Server i det som relaterar till Transact-SQL och frågeoptimeringsbeteenden endast för den angivna databasen, inte för hela servern.

Från och med kompatibilitetsläget 130 har alla nya frågeplaner som påverkar korrigeringar och funktioner avsiktligt lagts till på den nya kompatibilitetsnivån. Detta har gjorts för att minimera risken under uppgraderingar som uppstår till följd av prestandaförsämring på grund av ändringar i frågeplanen som eventuellt introduceras av nya frågeoptimeringsbeteenden.

Ur ett programperspektiv använder du den lägre kompatibilitetsnivån som en säkrare migreringsväg för att kringgå versionsskillnader, i de beteenden som styrs av relevant kompatibilitetsnivåinställning. Målet bör fortfarande vara att uppgradera till den senaste kompatibilitetsnivån någon gång, för att ärva några av de nya funktionerna, till exempel Intelligent frågebearbetning i SQL-databaser, men att göra det på ett kontrollerat sätt.

Mer information, inklusive det rekommenderade arbetsflödet för uppgradering av databasens kompatibilitetsnivå, finns i Metodtips för att uppgradera databasens kompatibilitetsnivå.

• Utgångna funktioner som introduceras i en viss SQL Server-version skyddas inte av kompatibilitetsnivå. Detta avser funktioner som har tagits bort från SQL Server Database Engine. Till exempel avbröts tipset FASTFIRSTROW i SQL Server 2012 (11.x) och ersattes med tipset OPTION (FAST n ) . Om du ställer in databasens kompatibilitetsnivå på 110 återställs inte det avbrutna tipset. Mer information om utgångna funktioner finns i Funktioner för utgående databasmotor i SQL Server.

• Icke-bakåtkompatibla ändringar som introduceras i en viss SQL Server-version kanske inte skyddas av kompatibilitetsnivå. Detta avser beteendeändringar mellan versioner av SQL Server Database Engine. Transact-SQL beteende skyddas vanligtvis av kompatibilitetsnivå. Men ändrade eller borttagna systemobjekt skyddas inte av kompatibilitetsnivå.

  Ett exempel på en icke-bakåtkompatibel ändring som skyddas av kompatibilitetsnivån är en implicit konvertering från datetime till datetime2-datatyper . Under databaskompatibilitetsnivå 130 visar dessa förbättrad noggrannhet genom att redovisa bråk millisekunder, vilket resulterar i olika konverterade värden. Om du vill återställa tidigare konverteringsbeteende anger du databasens kompatibilitetsnivå till 120 eller lägre.

  Exempel på icke-bakåtkompatibla ändringar som inte skyddas av kompatibilitetsnivån är:

  • Ändrade kolumnnamn i systemobjekt. I SQL Server 2012 (11.x) bytte kolumnen single_pages_kb i sys.dm_os_sys_info namn till pages_kb. Oavsett kompatibilitetsnivå genererar frågan SELECT single_pages_kb FROM sys.dm_os_sys_info fel 207 (ogiltigt kolumnnamn).

  • Systemobjekt har tagits bort. I SQL Server 2012 (11.x) togs bort sp_dboption . Oavsett kompatibilitetsnivå genererar -instruktionen EXEC sp_dboption 'AdventureWorks2022', 'autoshrink', 'FALSE'; fel 2812 (Could not find stored procedure 'sp_dboption').

    Mer information om icke-bakåtkompatibla ändringar finns i:

    • Icke-bakåtkompatibla ändringar av databasmotorfunktioner i SQL Server 2019
    • Icke-bakåtkompatibla ändringar av databasmotorfunktioner i SQL Server 2017
    • Icke-bakåtkompatibla ändringar av databasmotorfunktioner i SQL Server 2016

Skillnader mellan kompatibilitetsnivåer

För alla installationer av SQL Server är standardkompatibilitetsnivån associerad med den version av databasmotorn som visas i den här tabellen. För nytt utvecklingsarbete planerar du alltid att certifiera program på den senaste databaskompatibilitetsnivån.

Ny Transact-SQL syntax är inte gated av databaskompatibilitetsnivå, förutom när de kan bryta befintliga program genom att skapa en konflikt med användarens Transact-SQL kod. Dessa undantag dokumenteras i nästa avsnitt i den här artikeln som beskriver skillnaderna mellan specifika kompatibilitetsnivåer.

Databaskompatibilitetsnivån ger också bakåtkompatibilitet med tidigare versioner av SQL Server, eftersom databaser som är anslutna eller återställde från en tidigare version av SQL Server behåller sin befintliga kompatibilitetsnivå (om den är samma eller högre än den lägsta tillåtna kompatibilitetsnivån). Detta diskuterades i avsnittet Använda kompatibilitetsnivå för bakåtkompatibilitet i den här artikeln.

Från och med databaskompatibilitetsnivå 130 har alla nya korrigeringar och funktioner som påverkar frågeplaner endast lagts till på den senaste tillgängliga kompatibilitetsnivån, även kallad standardkompatibilitetsnivå. Detta har gjorts för att minimera risken under uppgraderingar som uppstår till följd av prestandaförsämring på grund av ändringar i frågeplanen, vilket kan komma att introduceras av nya frågeoptimeringsbeteenden.

De grundläggande planpåverkande ändringarna som bara läggs till på standardkompatibilitetsnivån för en ny version av databasmotorn är:

1. Frågeoptimerarkorrigeringar som släppts för tidigare SQL Server-versioner under spårningsflagga 4199 aktiveras automatiskt på standardkompatibilitetsnivån för en nyare SQL Server-version.

   Gäller för: SQL Server (från och med version SQL Server 2016 (13.x)), Azure SQL Database.

   När TILL exempel SQL Server 2016 (13.x) släpptes, aktiverades alla frågeoptimerkorrigeringar som släpptes för tidigare SQL Server-versioner (och respektive kompatibilitetsnivåer 100 till 120) automatiskt för databaser som använder STANDARDkompatibilitetsnivån för SQL Server 2016 (13.x) (130). Endast korrigeringar av frågeoptimeraren efter RTM måste vara explicit aktiverade.

   Om du vill aktivera frågeoptimerarkorrigeringar kan du använda följande metoder:

   • På servernivå med spårningsflagga 4199.
   • På databasnivå med QUERY_OPTIMIZER_HOTFIXES alternativet i ALTER DATABASE SCOPED CONFIGURATION (Transact-SQL).
   • På frågenivå med USE HINT 'ENABLE_QUERY_OPTIMIZER_HOTFIXES' genom att ändra frågan.
   • På frågenivå, med USE HINT 'ENABLE_QUERY_OPTIMIZER_HOTFIXES' utan kodändringar, med hjälp av funktionen Query Store-tips .

   Senare, när SQL Server 2017 (14.x) släpptes, aktiverades alla frågeoptimerkorrigeringar som släpptes efter SQL Server 2016 (13.x) RTM automatiskt för databaser med sql Server 2017 (14.x) standardkompatibilitetsnivå (140). Det här är ett kumulativt beteende som även omfattar alla tidigare versionskorrigeringar. Återigen behöver endast korrigeringar av frågeoptimeraren efter RTM aktiveras uttryckligen.

   I följande tabell sammanfattas det här beteendet:

   Databasmotorversion (DE)	Databaskompatibilitetsnivå	TF 4199	QO-ändringar från alla tidigare databaskompatibilitetsnivåer	QO-ändringar för (DE) version efter RTM
   13 (SQL Server 2016 (13.x))	100 till 120 130	Av På Av På	Handikappad Aktiverad Aktiverat Aktiverad	Handikappad Aktiverad Handikappad Aktiverad
   14 (SQL Server 2017 (14.x))	100 till 120 130 140	Av På Av På Av På	Handikappad Aktiverad Aktiverat Aktiverad Aktiverat Aktiverad	Handikappad Aktiverad Handikappad Aktiverad Handikappad Aktiverad
   15 (SQL Server 2019 (15.x)) och (Azure SQL Database)	100 till 120 130 till 140 150	Av På Av På Av På	Handikappad Aktiverad Aktiverat Aktiverad Aktiverat Aktiverad	Handikappad Aktiverad Handikappad Aktiverad Handikappad Aktiverad
   16 (SQL Server 2022 (16.x)) och (Azure SQL Database)	100 till 120 130 till 150 160	Av På Av På Av På	Handikappad Aktiverad Aktiverat Aktiverad Aktiverat Aktiverad	Handikappad Aktiverad Handikappad Aktiverad Handikappad Aktiverad
   17 (SQL Server 2025 (17.x) Förhandsversion, Azure SQL Database och SQL-databas i Microsoft Fabric)	100 till 120 130 till 160 170	Av På Av På Av På	Handikappad Aktiverad Aktiverat Aktiverad Aktiverat Aktiverad	Handikappad Aktiverad Handikappad Aktiverad Handikappad Aktiverad

   Frågeoptimerarkorrigeringar som åtgärdar fel resultat eller fel vid åtkomstöverträdelse skyddas inte av spårningsflagga 4199. Dessa korrigeringar anses inte vara valfria.

2. Ändringar i kardinalitetsestimatorn som släppts på SQL Server, Azure SQL Database och SQL-databasen i Microsoft Fabric aktiveras endast på standardkompatibilitetsnivån för en ny databasmotorversion, men inte på tidigare kompatibilitetsnivåer.

   När till exempel SQL Server 2016 (13.x) släpptes var ändringar i kardinalitetsuppskattningsprocessen endast tillgängliga för databaser med sql Server 2016 (13.x) standardkompatibilitetsnivå (130). Tidigare kompatibilitetsnivåer behöll kardinalitetsuppskattningsbeteendet som var tillgängligt före SQL Server 2016 (13.x).

   Senare, när SQL Server 2017 (14.x) släpptes, var nyare ändringar av kardinalitetsuppskattningsprocessen endast tillgängliga för databaser med sql Server 2017 (14.x) standardkompatibilitetsnivå (140). Databaskompatibilitetsnivå 130 behöll kardinalitetsuppskattningsbeteendet för SQL Server 2016 (13.x).

   I följande tabell sammanfattas det här beteendet:

   Databasmotorversion	Databaskompatibilitetsnivå	Ce-ändringar i ny version
   13 (SQL Server 2016 (13.x))	< 130 130	Handikappad Aktiverad
   14 (SQL Server 2017 (14.x))1	< 140 140	Handikappad Aktiverad
   15 (SQL Server 2019 (15.x))1	< 150 150	Handikappad Aktiverad
   16 (SQL Server 2022 (16.x))1	< 160 160	Handikappad Aktiverad
   17 (SQL Server 2025 (17.x) Förhandsversion)1	< 170 170	Handikappad Aktiverad

   ¹ Gäller även för Azure SQL Database och SQL Database i Microsoft Fabric.

Andra skillnader mellan specifika kompatibilitetsnivåer finns i nästa avsnitt i den här artikeln.

Skillnader mellan kompatibilitetsnivå 160 och nivå 170

I det här avsnittet beskrivs nya beteenden som introduceras med kompatibilitetsnivå 170.

Inställning för kompatibilitetsnivå på 160 eller lägre	Inställning för kompatibilitetsnivå på 170
För att skydda nyckelmaterialet för den symmetriska nyckeln lagrar databashuvudnyckeln och tjänsthuvudnyckeln SQL Server och Azure SQL nyckelmaterialet i krypterad form. Krypteringen använder utfyllnadsläget PKCS#1 v1.5.	För att skydda nyckelmaterialet för den symmetriska nyckeln lagrar databashuvudnyckeln och tjänsthuvudnyckeln SQL Server och Azure SQL nyckelmaterialet i krypterad form. Krypteringen använder utfyllnadsläget OAEP-256. I dm_database_encryption_keys visas encryptor_type som CERTIFICATE_OAEP_256 i stället för CERTIFICATE.
Reguljära uttryck kan användas för att matcha komplexa mönster och manipulera data i SQL Server och Azure SQL Database. Stöd för reguljära uttryck i T-SQL har lagts till. Vissa reguljära uttrycksfunktioner är inte tillgängliga på alla databaskompatibilitetsnivåer Mer information finns i Funktioner för reguljära uttryck.	Reguljära uttrycksfunktioner som REGEXP_LIKE, REGEXP_MATCHES och REGEXP_SPLIT_TO_TABLE har introducerats för att aktivera mönstermatchning, extrahering och delning direkt i T-SQL.
Möjligheten att skapa AI-inbäddningar (vektormatriser) från textuttryck har lagts till i databasmotorn. Mer information finns i AI-funktioner.	Introducerar funktionen AI_GENERATE_CHUNKS, som möjliggör segmentering av textindata för AI-modellförbrukning, vilket förbättrar integreringen med AI-tjänster.
Traditionellt skyddar databasmotorn DML-instruktioner från Halloween-problemet genom att introducera en Spool-operator i frågeplanen eller genom att dra nytta av en annan blockeringsoperator som redan finns i planen, till exempel en sorterings- eller hashmatchning.	Optimerat Halloween-skydd tar bort onödiga spooloperatorer och förbättrar frågeprestanda under DML-åtgärder där Halloween-skydd krävs.
Parametriserade frågor kan ha flera cachelagrade frågeplaner för olika selektivitetskategorier för en parameter. Optimering av parameterkänslig plan aktiveras som standard på kompatibilitetsnivå 160 endast för utvalda frågor	När optimering av parameterkänslig plan fungerar under kompatibilitetsnivå 170 är DML-frågestöd samt stöd för tempdb också tillgängligt
Parameterbaserade frågor som har valfria parametrar kan drabbas av suboptimala planer på grund av parametersniffning.	Frågeplansoptimering för valfria parametrar, förbättra prestanda genom att generera lämpligare planer för NULL- och icke-NULL-värden.

Skillnader mellan kompatibilitetsnivå 150 och nivå 160

I det här avsnittet beskrivs nya beteenden som introducerats med kompatibilitetsnivå 160.

Inställning för kompatibilitetsnivå på 150 eller lägre	Inställning för kompatibilitetsnivå på 160
Parametriserade frågor har en enda frågeplan baserat på de parametrar som används för den första körningen. Endast en frågeplan cachelagras och används för alla parametervärden. Detta kan göra att en frågeplan är ineffektiv för vissa värden i parametern, även kallat en parameterkänslig plan.	Parametriserade frågor kan ha flera cachelagrade frågeplaner för olika selektivitetskategorier för en parameter. Optimering av parameterkänslig plan är aktiverat som standard på kompatibilitetsnivå 160. Mer information finns i PSP-optimering.
Kardinalitetsuppskattning använder bara en standarduppsättning modellantaganden om den underliggande datadistributionen och användningsmönstren för alla databaser och frågor. Det enda sättet att ändra eller justera något av dessa antaganden är när användaren genomför en manuell process för att uttryckligen ange vilka modellantaganden som ska användas med hjälp av frågetips. Ingen intern justering kan göras för den här standardmodellen när en frågeplan har genererats.	Kardinalitetsuppskattning börjar med standarduppsättningen av modellantaganden om den underliggande datadistributionen och användningsmönstren, men efter vissa körningar för en viss fråga lär sig databasmotorn vilka olika uppsättningar av modellantaganden som kan ge mer exakta uppskattningar och justerar därför de antaganden som används för att bättre matcha datauppsättningen som efterfrågas. CE-feedback aktiveras som standard på kompatibilitetsnivå 160. Mer information finns i feedback om kardinalitetsuppskattning (CE).
Ingen automatisk bestämning av den optimala graden av parallellitet görs av databasmotorn. Information om hur du manuellt styr maximal grad av parallellitet (MAXDOP) på instans-, databas-, fråge- eller arbetsbelastningsnivåer finns i Serverkonfiguration: maximal grad av parallellitet	DoP-feedback (Grad av parallellitet) förbättrar frågeprestanda genom att identifiera parallellitetseffektivitet för upprepade frågor, baserat på förfluten tid och väntetider. Om parallellitetsanvändningen anses vara ineffektiv sänker DOP-feedback DOP för nästa körning av frågan, oavsett vad som är den konfigurerade DOP:en, och kontrollerar om det hjälper. DOP-feedback är inte aktiverat som standard. Aktivera databasomfattningskonfigurationen DOP_FEEDBACK i en databas för att aktivera DOP-feedback. Mer information finns i grad av parallellitet (DOP) feedback.

Skillnader mellan kompatibilitetsnivå 140 och nivå 150

I det här avsnittet beskrivs nya beteenden som introduceras med kompatibilitetsnivå 150.

Inställning för kompatibilitetsnivå på 140 eller lägre	Inställning för kompatibilitetsnivå på 150
Relationsdatalager och analysarbetsbelastningar kanske inte kan använda kolumnlagringsindex på grund av OLTP-omkostnader, brist på leverantörssupport eller andra begränsningar. Utan kolumnlagringsindex kan dessa arbetsbelastningar inte dra nytta av batchkörningsläget.	Batchkörningsläget är nu tillgängligt för analysarbetsbelastningar utan att behöva kolumnlagringsindex. Mer information finns i batchläge på radlagring.
Frågor i radläge som begär otillräckliga minnesbeviljande storlekar som resulterar i spill till disken kan fortsätta att ha problem med efterföljande körningar.	Frågor i radläge som begär otillräcklig minnesbeviljande storlekar som resulterar i spill till disk kan ha bättre prestanda vid efterföljande körningar. Mer information finns i feedback om minnesåtergivning i radläge.
Frågor i radläge som begär en överdriven minnesbeviljande storlek som resulterar i samtidighetsproblem kan fortsätta att ha problem med efterföljande körningar.	Frågor i radläge som begär en överdriven minnesbeviljande storlek som resulterar i samtidighetsproblem kan ha förbättrat samtidigheten vid efterföljande körningar. Mer information finns i feedback om minnesåtergivning i radläge.
Frågor som refererar till T-SQL-skalära UDF:er använder iterativ anrop, saknar kostnader och tvingar fram seriekörning.	T-SQL-skalära UDF:er omvandlas till motsvarande relationsuttryck som är "inlined" i den anropande frågan, vilket ofta resulterar i betydande prestandavinster. Mer information finns i T-SQL-skalär UDF-inlining.
Tabellvariabler använder en fast gissning för kardinalitetsuppskattningen. Om det faktiska antalet rader är mycket högre än det gissade värdet kan prestanda för nedströmsåtgärder drabbas.	Nya planer använder den faktiska kardinaliteten för tabellvariabeln som påträffades vid den första kompilering i stället för en fast gissning. Mer information finns i uppskjuten kompilering av tabellvariabel.

Mer information om frågebearbetningsfunktioner som är aktiverade på databaskompatibilitetsnivå 150 finns i Nyheter i SQL Server 2019 och Intelligent frågebearbetning i SQL-databaser.

Skillnader mellan kompatibilitetsnivå 130 och nivå 140

I det här avsnittet beskrivs nya beteenden som introduceras med kompatibilitetsnivå 140.

Inställning för kompatibilitetsnivå på 130 eller lägre	Inställning för kompatibilitetsnivå på 140
Kardinalitetsuppskattningar för instruktioner som refererar till tabellvärdesfunktioner med flera instruktioner använder en fast rad gissning.	Kardinalitetsuppskattningar för berättigade instruktioner som refererar till tabellvärdesfunktioner med flera instruktioner använder funktionens faktiska kardinalitet. Detta aktiveras via interfolierad körning för tabellvärdesfunktioner med flera instruktioner.
Batchlägesfrågor som begär otillräcklig minnesbeviljande storlekar som resulterar i spill till disken kan fortsätta att ha problem med efterföljande körningar.	Batch-lägesfrågor som begär otillräcklig minnesbeviljande storlekar som resulterar i spill till disk kan ha bättre prestanda vid efterföljande körningar. Detta aktiveras via feedback om minnesåtergivning i batchläge som uppdaterar storleken på minnesbidraget för en cachelagrad plan om spill har inträffat för batchlägesoperatorer.
Frågor i batchläge som begär en överdriven minnesbeviljande storlek som resulterar i samtidighetsproblem kan fortsätta att ha problem med efterföljande körningar.	Frågor i batchläge som begär en överdriven minnesbeviljande storlek som resulterar i samtidighetsproblem kan ha förbättrat samtidigheten vid efterföljande körningar. Detta aktiveras via feedback om minnesbeviljande i batchläge som uppdaterar storleken på minnesbeviljande för en cachelagrad plan om en för stor mängd ursprungligen begärdes.
Batchlägesfrågor som innehåller kopplingsoperatorer är berättigade till tre fysiska kopplingsalgoritmer, inklusive kapslad loop, hashkoppling och sammanslagningskoppling. Om kardinalitetsuppskattningar är felaktiga för kopplingsindata kan en olämplig kopplingsalgoritm väljas. Om detta inträffar blir prestandan sämre och den olämpliga kopplingsalgoritmen fortsätter att användas tills den cachelagrade planen omkompileras.	Det finns ytterligare en kopplingsoperator som kallas adaptiv koppling. Om kardinalitetsuppskattningar är felaktiga för indata för yttre byggkoppling kan en olämplig kopplingsalgoritm väljas. Om detta inträffar och -instruktionen är berättigad till en anpassningsbar koppling, används en kapslad loop för mindre kopplingsindata och en hash-koppling används dynamiskt för större kopplingsindata utan att behöva kompileras om.
Triviala planer som refererar till Columnstore-index är inte berättigade till körning av batchläge.	En trivial plan som refererar till Columnstore-index tas bort till förmån för en plan som är berättigad till körning av batchläge.
sp_execute_external_script UDX-operatorn kan bara köras i radläge.	sp_execute_external_script UDX-operatorn är berättigad till körning av batchläge.
Tabellvärdesfunktioner med flera instruktioner (TVF:er) har inte interfolierad körning	Interfolierad körning för TVF:er med flera instruktioner för att förbättra planens kvalitet.

Korrigeringar som var under spårningsflagga 4199 i tidigare versioner av SQL Server före SQL Server 2017 är nu aktiverade som standard. Med kompatibilitetsläge 140. Spårningsflagga 4199 gäller fortfarande för nya frågeoptimerkorrigeringar som släpps efter SQL Server 2017. Information om spårningsflagga 4199 finns i Spårningsflagga 4199.

Skillnader mellan kompatibilitetsnivå 120 och nivå 130

I det här avsnittet beskrivs nya beteenden som introduceras med kompatibilitetsnivå 130.

Inställning för kompatibilitetsnivå på 120 eller lägre	Inställning för kompatibilitetsnivå på 130
INSERT i en INSERT-SELECT-instruktion är enkeltrådad.	INSERT i en INSERT-SELECT-instruktion är flera trådar eller kan ha en parallell plan.
Frågor i en minnesoptimerad tabell körs med en tråd.	Frågor i en minnesoptimerad tabell kan nu ha parallella planer.
Introducerade sql 2014-kardinalitetsestimatorn CardinalityEstimationModelVersion="120"	Ytterligare kardinalitetsuppskattning (CE) Förbättringar med kardinalitetsuppskattningsmodellen 130, som visas från en frågeplan. CardinalityEstimationModelVersion="130"
Batchläge jämfört med radläge ändras med Columnstore-index: Sortering i en tabell med Columnstore-index är i radläge Fönsterfunktionsaggregat fungerar i radläge, till exempel LAG eller LEAD Frågor i Columnstore-tabeller med flera distinkta satser som körs i radläge Frågor som körs under MAXDOP 1 eller med en serieplan som körs i radläge	Batchläge jämfört med radläge ändras med Columnstore-index: Sortering i en tabell med ett Columnstore-index är nu i batchläge Fönsteraggregeringar fungerar nu i batchläge, till exempel LAG eller LEAD Frågor i Columnstore-tabeller med flera distinkta satser fungerar i Batch-läge Frågor som körs under MAXDOP 1 eller med en seriell plan körs i Batch-läge
Statistik kan uppdateras automatiskt.	Logiken som automatiskt uppdaterar statistik är mer aggressiv i stora tabeller. I praktiken bör detta minska de fall där kunder har sett prestandaproblem i frågor där nyligen infogade rader efterfrågas ofta men där statistiken inte har uppdaterats för att inkludera dessa värden.
Spårning 2371 är AV som standard i SQL Server 2014 (12.x).	Spårning 2371 är PÅ som standard i SQL Server 2016 (13.x). Spårningsflagga 2371 instruerar den automatiska statistikuppdateringen att prova en mindre men klokare delmängd av rader, i en tabell som har många rader. En förbättring är att ta med fler rader som nyligen infogats i exemplet. En annan förbättring är att låta frågor köras medan uppdateringsstatistikprocessen körs i stället för att blockera frågan.
För nivå 120 samplas statistik av en enkeltrådad process.	För nivå 130 samplas statistik av en process med flera trådar (parallell process).
253 inkommande sekundärnycklar är gränsen.	En viss tabell kan refereras till med upp till 10 000 inkommande sekundärnycklar eller liknande referenser. Begränsningar finns i Skapa sekundärnyckelrelationer.
De inaktuella algoritmerna MD2, MD4, MD5, SHA och SHA1 är tillåtna.	Endast SHA2_256- och SHA2_512 hash-algoritmer tillåts.
	SQL Server 2016 (13.x) innehåller förbättringar i vissa datatypers konverteringar och vissa (mestadels ovanliga) åtgärder. Mer information finns i FÖRBÄTTRINGAR av SQL Server och Azure SQL Database i hanteringen av vissa datatyper och ovanliga åtgärder.
Funktionen STRING_SPLIT är inte tillgänglig.	Funktionen STRING_SPLIT är tillgänglig under kompatibilitetsnivå 130 eller senare. Om databasens kompatibilitetsnivå är lägre än 130 kommer SQL Server inte att kunna hitta och köra STRING_SPLIT funktionen.

Korrigeringar som var under spårningsflagga 4199 i tidigare versioner av SQL Server före SQL Server 2016 (13.x) är nu aktiverade som standard. Med kompatibilitetsläge 130. Spårningsflagga 4199 gäller fortfarande för nya frågeoptimerkorrigeringar som släpps efter SQL Server 2016 (13.x). Om du vill använda den äldre frågeoptimeraren i SQL Database måste du välja kompatibilitetsnivå 110. Information om spårningsflagga 4199 finns i Spårningsflagga 4199.

Skillnader mellan lägre kompatibilitetsnivåer och nivå 120

I det här avsnittet beskrivs nya beteenden som introduceras med kompatibilitetsnivå 120.

Inställning för kompatibilitetsnivå på 110 eller lägre	Inställning för kompatibilitetsnivå på 120
Den äldre frågeoptimeraren används.	SQL Server 2014 (12.x) innehåller betydande förbättringar av komponenten som skapar och optimerar frågeplaner. Den här nya frågeoptimerarfunktionen är beroende av användningen av databasens kompatibilitetsnivå 120. Nya databasprogram bör utvecklas med hjälp av databaskompatibilitetsnivå 120 för att dra nytta av dessa förbättringar. Program som migreras från tidigare versioner av SQL Server bör noggrant testas för att bekräfta att goda prestanda bibehålls eller förbättras. Om prestandan försämras kan du ange databaskompatibilitetsnivån till 110 eller tidigare för att använda den äldre frågeoptimerarmetoden. Databaskompatibilitetsnivå 120 använder en ny kardinalitetsestimator som är justerad för modern datalagerhantering och OLTP-arbetsbelastningar. Innan du anger databaskompatibilitetsnivån till 110 på grund av prestandaproblem kan du läsa rekommendationerna i avsnittet Frågeplaneri Nyheter i SQL Server 2016.
I kompatibilitetsnivåer som är lägre än 120 ignoreras språkinställningen när ett datumvärde konverteras till ett strängvärde. Det här beteendet är endast specifikt för datumtypen . Se exempel B i avsnittet Exempel .	Språkinställningen ignoreras inte när ett datumvärde konverteras till ett strängvärde.
Rekursiva referenser till höger i en EXCEPT sats skapar en oändlig loop. Exempel C i avsnittet Exempel visar det här beteendet.	Rekursiva referenser i en EXCEPT sats genererar ett fel i enlighet med ANSI SQL-standarden.
Rekursivt gemensamt tabelluttryck (CTE) tillåter dubbletter av kolumnnamn.	Rekursiv CTE tillåter inte dubbletter av kolumnnamn.
Inaktiverade utlösare aktiveras om utlösarna ändras.	Om du ändrar en utlösare ändras inte utlösarens tillstånd (aktiverat eller inaktiverat).
OUTPUT INTO-tabellsatsen ignorerar IDENTITY_INSERT SETTING = OFF och tillåter att explicita värden infogas.	Du kan inte infoga explicita värden för en identitetskolumn i en tabell när IDENTITY_INSERT är inställt på OFF.
När databasens inneslutning är inställd på partiell kan validering $action av fältet i instruktionens OUTPUT sats MERGE returnera ett sorteringsfel.	Sortering av de värden som returneras av instruktionen $action i en MERGE -instruktion är databassortering i stället för serversortering och ett sorteringskonfliktsfel returneras inte.
En SELECT INTO instruktion skapar alltid en enkeltrådad infogningsåtgärd.	En SELECT INTO instruktion kan skapa en parallell infogningsåtgärd. När du infogar ett stort antal rader kan den parallella åtgärden förbättra prestandan.

Skillnader mellan lägre kompatibilitetsnivåer och nivåer 100 och 110

I det här avsnittet beskrivs nya beteenden som introduceras med kompatibilitetsnivå 110. Det här avsnittet gäller även för kompatibilitetsnivåer över 110.

Inställning för kompatibilitetsnivå på 100 eller lägre	Kompatibilitetsnivåinställning på minst 110
CLR-databasobjekt (Common Language Runtime) körs med version 4 av CLR. Vissa beteendeändringar som introduceras i version 4 av CLR undviks dock. Mer information finns i Nyheter i CLR-integrering?	CLR-databasobjekt körs med version 4 av CLR.
XQuery-funktionerna string-length och substring räknar varje surrogat som två tecken.	XQuery-funktionerna string-length och substring räknar varje surrogat som ett tecken.
PIVOT tillåts i en rekursiv CTE-fråga (Common Table Expression). Frågan returnerar dock felaktiga resultat när det finns flera rader per gruppering.	PIVOT tillåts inte i en rekursiv CTE-fråga (Common Table Expression). Ett fel returneras.
RC4-algoritmen stöds endast för bakåtkompatibilitet. Nytt material kan bara krypteras med hjälp av RC4 eller RC4_128 när databasen är på kompatibilitetsnivå 90 eller 100. (Rekommenderas inte.) I SQL Server 2012 (11.x) kan material som krypterats med RC4 eller RC4_128 dekrypteras på valfri kompatibilitetsnivå.	Nytt material kan inte krypteras med hjälp av RC4 eller RC4_128. Använd en nyare algoritm, till exempel en av AES-algoritmerna i stället. I SQL Server 2012 (11.x) kan material som krypterats med RC4 eller RC4_128 dekrypteras på valfri kompatibilitetsnivå.
Standardformatet för CAST och CONVERT åtgärder för tids - och datetime2-datatyper är 121 förutom när någon av typerna används i ett beräknat kolumnuttryck. För beräknade kolumner är standardformatet 0. Det här beteendet påverkar beräknade kolumner när de skapas, används i frågor som involverar automatisk parameterisering eller används i villkorsdefinitioner. Exempel D i avsnittet Exempel visar skillnaden mellan formatmallarna 0 och 121. Det visar inte beteendet som beskrivs ovan. Mer information om datum - och tidsformat finns i CAST och CONVERT.	Under kompatibilitetsnivå 110 är standardformatet för CAST och CONVERT åtgärder på datatyperna tid och datetime2 alltid 121. Om frågan förlitar sig på det gamla beteendet använder du en kompatibilitetsnivå som är mindre än 110 eller anger uttryckligen formatet 0 i den berörda frågan. Om du uppgraderar databasen till kompatibilitetsnivå 110 ändras inte användardata som har lagrats på disken. Du måste korrigera dessa data manuellt efter behov. Om du till exempel använde SELECT INTO för att skapa en tabell från en källa som innehöll ett beräknat kolumnuttryck som beskrivs ovan, lagras data (med format 0) i stället för själva den beräknade kolumndefinitionen. Du skulle behöva uppdatera dessa data manuellt för att matcha format 121.
Operatorn + (Addition) kan tillämpas på en operand av typen datum, tid, datetime2 eller datetimeoffset om den andra operanden har typ datetime eller smalldatetime.	Om du försöker tillämpa additionsoperatorn på en operand av typen datum, tid, datetime2 eller datetimeoffset och en operand av typen datetime eller smalldatetime orsakas fel 402.
Alla kolumner i fjärrtabeller av typen smalldatetime som refereras i en partitionerad vy mappas som datetime. Motsvarande kolumner i lokala tabeller (i samma ordningstal i urvalslistan) måste vara av typen datetime.	Alla kolumner i fjärrtabeller av typen smalldatetime som refereras i en partitionerad vy mappas som smalldatetime. Motsvarande kolumner i lokala tabeller (i samma ordningstal i urvalslistan) måste vara av typen smalldatetime. När du har uppgraderat till 110 misslyckas den distribuerade partitionerade vyn på grund av datatypens matchningsfel. Du kan lösa detta genom att ändra datatypen i fjärrtabellen till datetime eller ange kompatibilitetsnivån för den lokala databasen till 100 eller lägre.
SOUNDEX funktionen implementerar följande regler: 1) Versaler H eller versaler W ignoreras när två konsonanter som har samma nummer i SOUNDEX koden separeras. 2) Om de två första tecknen i character_expression har samma nummer i SOUNDEX koden inkluderas båda tecknen. Om en uppsättning konsonanter sida vid sida har samma nummer i SOUNDEX koden undantas alla förutom den första.	SOUNDEX funktionen implementerar följande regler: 1) Om versaler H eller versaler W separerar två konsonanter som har samma nummer i SOUNDEX koden ignoreras konsonanten till höger 2) Om en uppsättning konsonanter sida vid sida har samma nummer i SOUNDEX koden undantas alla utom den första. De ytterligare reglerna kan göra att de värden som beräknas av SOUNDEX funktionen skiljer sig från de värden som beräknas under tidigare kompatibilitetsnivåer. När du har uppgraderat till kompatibilitetsnivå 110 kan du behöva återskapa de index, heaps eller CHECK-begränsningar som använder SOUNDEX funktionen. Mer information finns i SOUNDEX.
STRING_AGGär tillgängligt utan .<order_clause>	STRING_AGG är tillgängligt med en valfri <order_clause>. Mer information finns i STRING_AGG

Skillnader mellan kompatibilitetsnivå 90 och nivå 100

I det här avsnittet beskrivs nya beteenden som introduceras med kompatibilitetsnivå 100.

Inställning för kompatibilitetsnivå på 90	Inställning för kompatibilitetsnivå på 100	Risk för påverkan
Inställningen QUOTED_IDENTIFIER är alltid inställd på PÅ för tabellvärdesfunktioner för flera delstater när de skapas oavsett inställning på sessionsnivå.	Sessionsinställningen QUOTED IDENTIFIER respekteras när tabellvärdesfunktioner för flera delstater skapas.	Medel
När du skapar eller ändrar en partitionsfunktion utvärderas datetime - och smalldatetime-literaler i funktionen förutsatt att US_English som språkinställning.	Den aktuella språkinställningen används för att utvärdera datetime - och smalldatetime-literaler i partitionsfunktionen.	Medel
Satsen FOR BROWSE tillåts (och ignoreras) i INSERT och SELECT INTO -instruktioner.	Satsen FOR BROWSE tillåts inte i INSERT - och SELECT INTO -instruktioner.	Medel
Fulltextpredikat tillåts i OUTPUT -satsen.	Fulltextpredikat tillåts inte i OUTPUT -satsen.	Låg
CREATE FULLTEXT STOPLIST, ALTER FULLTEXT STOPLISToch DROP FULLTEXT STOPLIST stöds inte. Systemstopplistan associeras automatiskt med nya fulltextindex.	CREATE FULLTEXT STOPLIST, ALTER FULLTEXT STOPLISToch DROP FULLTEXT STOPLIST stöds.	Låg
MERGE tillämpas inte som ett reserverat nyckelord.	MERGE är ett helt reserverat nyckelord. -instruktionen MERGE stöds under både 100- och 90-kompatibilitetsnivåer.	Låg
<dml_table_source> Om du använder argumentet i INSERT-instruktionen genereras ett syntaxfel.	Du kan samla in resultatet av en OUTPUT-sats i en kapslad INSERT-, UPDATE-, DELETE- eller MERGE-instruktion och infoga resultaten i en måltabell eller vy. Detta görs med argumentet <dml_table_source> för INSERT-instruktionen.	Låg
Såvida inte NOINDEX anges, DBCC CHECKDB eller DBCC CHECKTABLE utför både fysiska och logiska konsekvenskontroller i en enda tabell eller indexerad vy och på alla dess icke-illustrerade och XML-index. Rumsliga index stöds inte.	Såvida inte NOINDEX anges, DBCC CHECKDB eller DBCC CHECKTABLE utför både fysiska och logiska konsekvenskontroller på en enskild tabell och på alla dess icke-illustrerade index. På XML-index, rumsliga index och indexerade vyer utförs dock endast fysiska konsekvenskontroller som standard. Om WITH EXTENDED_LOGICAL_CHECKS anges utförs logiska kontroller på indexerade vyer, XML-index och rumsliga index, där de finns. Som standard utförs fysiska konsekvenskontroller innan den logiska konsekvensen kontrolleras. Om NOINDEX också anges utförs endast de logiska kontrollerna.	Låg
När en OUTPUT-sats används med en DML-instruktion (datamanipuleringsspråk) och ett körningsfel inträffar under instruktionskörningen avslutas hela transaktionen och återställs.	När en OUTPUT sats används med en DML-instruktion (datamanipuleringsspråk) och ett körningsfel inträffar under körningen av instruktionen beror beteendet på inställningen SET XACT_ABORT . Om SET XACT_ABORT är AV avslutas instruktionen med ett instruktionsfel som genereras av DML-instruktionen OUTPUT med satsen, men körningen av batchen fortsätter och transaktionen återställs inte. Om SET XACT_ABORT är PÅ avslutas batchen av alla körningsfel som genereras av DML-instruktionen med output-satsen och transaktionen återställs.	Låg
KUB och SAMMANSLAGNING tillämpas inte som reserverade nyckelord.	CUBE och ROLLUP är reserverade nyckelord i GROUP BY-satsen.	Låg
Strikt validering tillämpas på element av TYPEN XML anyType .	Lax-validering tillämpas på element av typen anyType . Mer information finns i Komponenter för jokertecken och innehållsverifiering.	Låg
De särskilda attributen xsi:nil och xsi:type kan inte efterfrågas eller ändras av språkinstruktioner för datamanipulering. Det innebär att /e/@xsi:nil det misslyckas medan /e/@* attributen xsi:nil och xsi:type ignoreras. Returnerar dock /e attributen xsi:nil och xsi:type för konsekvens med SELECT xmlCol, även om xsi:nil = "false".	De särskilda attributen xsi:nil och xsi:type lagras som vanliga attribut och kan efterfrågas och ändras. Om du till exempel kör frågan SELECT x.query('a/b/@*') returneras alla attribut, inklusive xsi:nil och xsi:type. Om du vill undanta dessa typer i frågan ersätter du @* med @*[namespace-uri(.) != "infoga xsi-namnområdes-URI" och inte (local-name(.) = "type" eller local-name(.) ="nil".	Låg
En användardefinierad funktion som konverterar ett XML-konstantsträngsvärde till en SQL Server datetime-typ markeras som deterministisk.	En användardefinierad funktion som konverterar ett XML-konstantsträngvärde till en SQL Server datetime-typ markeras som icke-deterministisk.	Låg
XML-union och listtyper stöds inte fullt ut.	Union- och listtyperna stöds fullt ut, inklusive följande funktioner: Union av lista Union av unionen Lista över atomiska typer Lista över union	Låg
De SET-alternativ som krävs för en xQuery-metod verifieras inte när metoden finns i en vy eller infogad tabellvärdesfunktion.	DE SET-alternativ som krävs för en xQuery-metod verifieras när metoden finns i en vy eller infogad tabellvärdesfunktion. Ett fel utlöses om set-alternativen för metoden har angetts felaktigt.	Låg
XML-attributvärden som innehåller radslutstecken (vagnretur och radmatning) normaliseras inte enligt XML-standarden. Båda tecknen returneras alltså i stället för ett enda radmatningstecken.	XML-attributvärden som innehåller radslutstecken (vagnretur och radmatning) normaliseras enligt XML-standarden. Det vill: alla radbrytningar i externa parsade entiteter (inklusive dokumententiteten) normaliseras vid indata genom att översätta både sekvensen med två tecken #xD #xA och alla #xD som inte följs av #xA till ett enda #xA tecken. Program som använder attribut för att transportera strängvärden som innehåller radslutstecken får inte tillbaka dessa tecken när de skickas. Undvik normaliseringsprocessen genom att använda xml-numeriska teckenentiteter för att koda alla radslutstecken.	Låg
Kolumnegenskaperna ROWGUIDCOL och IDENTITY kan felaktigt namnges som en begränsning. Instruktionen CREATE TABLE T (C1 int CONSTRAINT MyConstraint IDENTITY) körs till exempel, men villkorsnamnet bevaras inte och är inte tillgängligt för användaren.	Kolumnegenskaperna ROWGUIDCOL och IDENTITY kan inte namnges som en begränsning. Fel 156 returneras.	Låg
Att uppdatera kolumner med hjälp av en dubbelriktad tilldelning, till exempel UPDATE T1 SET @v = column_name = <expression> kan ge oväntade resultat eftersom variabelns livevärde kan användas i andra satser, till exempel -WHEREinstruktionen ON under instruktionskörningen i stället för instruktionens startvärde. Detta kan göra att predikatens betydelser ändras oförutsägbart per rad. Det här beteendet gäller endast när kompatibilitetsnivån är inställd på 90.	Om du uppdaterar kolumner med hjälp av en dubbelriktad tilldelning genereras förväntade resultat eftersom endast instruktionens startvärde för kolumnen används under körningen av instruktionen.	Låg
Variabeltilldelning tillåts i en instruktion som innehåller en operator på den översta nivån UNION , men returnerar oväntade resultat. Läs mer i exempel E.	Variabeltilldelning tillåts inte i en instruktion som innehåller en UNION-operator på toppnivå. Fel 10734 returneras. Hitta en föreslagen omskrivning i exempel E.	Låg
ODBC-funktionen {fn CONVERT()} använder språkets standarddatumformat. För vissa språk är standardformatet YDM, vilket kan resultera i konverteringsfel när CONVERT() kombineras med andra funktioner, till exempel , som {fn CURDATE()}förväntar sig ett YMD-format.	ODBC-funktionen {fn CONVERT()} använder format 121 (ett språkoberoende YMD-format) när du konverterar till ODBC-datatyperna SQL_TIMESTAMP, SQL_DATE, SQL_TIME, SQLDATE, SQL_TYPE_TIME och SQL_TYPE_TIMESTAMP.	Låg
Datetime-inbyggda värden, till exempel DATEPART kräver inte att strängindatavärden är giltiga datetime-literaler. Till exempel SELECT DATEPART (year, '2007/05-30') kompileras.	Datetime-inbyggda värden som DATEPART kräver att strängindatavärden är giltiga datetime-literaler. Fel 241 returneras när en ogiltig datetime-literal används.	Låg
Avslutande blanksteg som anges i den första indataparametern till funktionen REPLACE trimmas när parametern är av typen tecken. I instruktionen SELECT '<' + REPLACE(CONVERT(char(6), 'ABC '), ' ', 'L') + '>'utvärderas till exempel värdet 'ABC ' felaktigt som 'ABC'.	Avslutande blanksteg bevaras alltid. För program som förlitar sig på funktionens tidigare beteende använder du RTRIM funktionen när du anger den första indataparametern för funktionen. Följande syntax återskapar till exempel SQL Server 2005-beteendet: SELECT '<' + REPLACE(RTRIM(CONVERT(char(6), 'ABC ')), ' ', 'L') + '>'.	Låg

Reserverade nyckelord

Kompatibilitetsinställningen avgör också de nyckelord som är reserverade av databasmotorn. I följande tabell visas de reserverade nyckelord som introduceras av var och en av kompatibilitetsnivåerna.

Inställning för kompatibilitetsnivå	Reserverade nyckelord
130	Ska fastställas.
120	Ingen.
110	WITHIN GROUP, TRY_CONVERT, SEMANTICKEYPHRASETABLE, , , SEMANTICSIMILARITYDETAILSTABLESEMANTICSIMILARITYTABLE
100	CUBE, , MERGEROLLUP
90	EXTERNAL, PIVOT, UNPIVOT, , , REVERTTABLESAMPLE

På en viss kompatibilitetsnivå innehåller de reserverade nyckelorden alla nyckelord som introduceras på eller under den nivån. För program på nivå 110 är därför alla nyckelord som anges i föregående tabell reserverade. På de lägre kompatibilitetsnivåerna förblir nyckelord på nivå 100 giltiga objektnamn, men språkfunktionerna på nivå 110 som motsvarar dessa nyckelord är inte tillgängliga.

När ett nyckelord har introducerats förblir det reserverat. Till exempel är det reserverade nyckelordet PIVOT, som introducerades på kompatibilitetsnivå 90, också reserverat i nivåerna 100, 110 och 120.

Om ett program använder en identifierare som är reserverad som ett nyckelord för dess kompatibilitetsnivå misslyckas programmet. Du kan kringgå detta genom att omsluta identifieraren mellan hakparenteser ([]) eller citattecken (""); Om du till exempel vill uppgradera ett program som använder identifieraren EXTERNAL till kompatibilitetsnivå 90 kan du ändra identifieraren till antingen [EXTERNAL] eller "EXTERNAL".

Mer information finns i Reserverade nyckelord.

Behörigheter

Kräver ALTER behörighet för databasen.

Exempel

A. Ändra kompatibilitetsnivån

I följande exempel ändras kompatibilitetsnivån för AdventureWorks2022 till 150, standardvärdet för SQL Server 2019 (15.x).

ALTER DATABASE AdventureWorks2022
SET COMPATIBILITY_LEVEL = 150;
GO

I följande exempel returneras kompatibilitetsnivån för den aktuella databasen.

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

B. Ignorera SET LANGUAGE-instruktionen förutom under kompatibilitetsnivå 120 eller senare

Följande fråga ignorerar -instruktionen SET LANGUAGE förutom under kompatibilitetsnivå 120 eller senare.

SET DATEFORMAT dmy;

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

SET LANGUAGE dutch;

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

Resultat när kompatibilitetsnivån är mindre än 120: 12 May 2011

Resultat när kompatibilitetsnivån är inställd på 120 eller högre: 12 mei 2011

C. För kompatibilitetsnivåinställningen 110 eller lägre skapar rekursiva referenser till höger i en EXCEPT-sats en oändlig loop

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. Skillnaden mellan format 0 och 121

När kompatibilitetsnivån är lägre än 110 är standardformatet för CAST och CONVERT åtgärder i datatyperna tid och datetime2 121, förutom när någon av typerna används i ett beräknat kolumnuttryck. För beräknade kolumner är standardformatet 0.

När kompatibilitetsnivån är 110 eller högre är standardformatet för CAST och CONVERT åtgärder i datatyperna tid och datetime2 alltid 121. Mer information finns i Skillnader mellan lägre kompatibilitetsnivåer och nivåer 100 och 110 .

Mer information om datum- och tidsformat finns i CAST och 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

Detta returnerar resultat som följande:

TimeStyle0	TimeStyle121	Datetime2Style0	Datetime2Style121
15:15	15:15:35.8100000	7 jun 2011 15:15	2011-06-07 15:15:35.8130000

E. Variabeltilldelning – UNION-operator på översta nivån

Under inställningen för databaskompatibilitetsnivå på 90 tillåts variabeltilldelning i en instruktion som innehåller en UNION-operator på toppnivå, men returnerar oväntade resultat. I följande instruktioner tilldelas till exempel den lokala variabeln @v värdet för kolumnen BusinessEntityID från unionen av två tabeller. Per definition tilldelas variabeln det sista värdet som returneras när SELECT-instruktionen returnerar mer än ett värde. I det här fallet tilldelas variabeln korrekt det sista värdet, men resultatuppsättningen för SELECT UNION-instruktionen returneras också.

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;

Under inställningen för databaskompatibilitetsnivå på 100 och högre tillåts inte variabeltilldelning i en instruktion som innehåller en UNION-operator på toppnivå. Fel 10734 returneras.

Lös felet genom att skriva om frågan enligt följande exempel.

DECLARE @v AS INT;

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

SELECT @v;

Relaterat innehåll

• Behåll prestandastabilitet under uppgraderingen till nyare SQL Server
• Ändra databasens kompatibilitetsnivå och använd Query Store
• Kompatibilitetscertifiering
• ÄNDRA DATABAS (Transact-SQL)
• Uppgradera databaser med hjälp av Frågejusteringsassistenten
• SKAPA DATABAS
• Visa eller ändra kompatibilitetsnivån för en databas
• Query Store-anvisningar