Ä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 ALTER DATABASE alternativ finns i ÄNDRA DATABAS.

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 | 90 | 80 }

Arguments

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å):

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.

Remarks

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.

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 Förhandsversionen av Microsoft Fabric.

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

Standardkompatibilitetsnivån är 170 för nyligen skapade databaser med uppdateringsprincipen Always-up-to-date eller SQL Server 2025 för 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	Off On Off On	Disabled Enabled Enabled Enabled	Disabled Enabled Disabled Enabled
   14 (SQL Server 2017 (14.x))	100 till 120 130 140	Off On Off On Off On	Disabled Enabled Enabled Enabled Enabled Enabled	Disabled Enabled Disabled Enabled Disabled Enabled
   15 (SQL Server 2019 (15.x)) och (Azure SQL Database)	100 till 120 130 till 140 150	Off On Off On Off On	Disabled Enabled Enabled Enabled Enabled Enabled	Disabled Enabled Disabled Enabled Disabled Enabled
   16 (SQL Server 2022 (16.x)) och (Azure SQL Database)	100 till 120 130 till 150 160	Off On Off On Off On	Disabled Enabled Enabled Enabled Enabled Enabled	Disabled Enabled Disabled Enabled Disabled Enabled
   17 (SQL Server 2025 (17.x) Förhandsversion, Azure SQL Database och SQL-databas i Förhandsversion av Microsoft Fabric)	100 till 120 130 till 160 170	Off On Off On Off On	Disabled Enabled Enabled Enabled Enabled Enabled	Disabled Enabled Disabled Enabled Disabled Enabled

   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 Database i Microsoft Fabric Preview 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	Disabled Enabled
   14 (SQL Server 2017 (14.x))1	< 140 140	Disabled Enabled
   15 (SQL Server 2019 (15.x))1	< 150 150	Disabled Enabled
   16 (SQL Server 2022 (16.x))1	< 160 160	Disabled Enabled
   17 (SQL Server 2025 (17.x) Förhandsversion)1	< 170 170	Disabled Enabled

   ¹ Gäller även för Azure SQL Database och SQL Database i Förhandsversionen av 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.

Skillnader mellan kompatibilitetsnivå 150 och nivå 160

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

Skillnader mellan kompatibilitetsnivå 140 och nivå 150

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

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.

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. Mer information 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.

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. Mer information 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.

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.

Skillnader mellan kompatibilitetsnivå 90 och nivå 100

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

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.

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.

Permissions

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

Examples

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:

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 operator på den översta nivån UNION , 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 instruktionen SELECT returnerar mer än ett värde. I det här fallet tilldelas variabeln korrekt det sista värdet, men resultatuppsättningen för -instruktionen SELECT UNION 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 operator på toppnivå UNION . 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