Livello di compatibilità ALTER DATABASE (Transact-SQL)

Si applica a: SQL Server (tutte le versioni supportate) Database SQL di Azure Istanza gestita di SQL di Azure

Imposta i comportamenti di Transact-SQL e dell'elaborazione delle query in modo che risultino compatibili con la versione specificata del motore SQL. Per altre opzioni di ALTER DATABASE, vedere ALTER DATABASE.

Per altre informazioni sulle convenzioni di sintassi, vedere Convenzioni della sintassi Transact-SQL.

Sintassi

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

Nota

Per visualizzare la sintassi Transact-SQL per SQL Server 2014 e versioni precedenti, vedere Documentazione delle versioni precedenti.

Argomenti

database_name

Nome del database da modificare.

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

È la versione di SQL Server con cui il database deve essere reso compatibile. È possibile configurare i valori di livello di compatibilità seguenti (non tutte le versioni supportano tutti i livelli di compatibilità elencati):

Prodotto Versione del motore di database Designazione del livello di compatibilità predefinito Valori del livello di compatibilità supportato
SQL Server 2022 (16.x) - anteprima 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
database SQL di Azure 12 150 160, 150, 140, 130, 120, 110, 100
Istanza gestita di SQL di Azure 12 150 160, 150, 140, 130, 120, 110, 100
SQL Server 2016 (13.x) 13 130 130, 120, 110, 100
SQL Server 2014 (12.x) 12 120 120, 110, 100
SQL Server 2012 (11.x) 11 110 110, 100, 90
SQL Server 2008 R2 10.5 100 100, 90, 80
SQL Server 2008 10 100 100, 90, 80
SQL Server 2005 (9.x) 9 90 90, 80
SQL Server 2000 (8.x) 8 80 80

Importante

I numeri di versione del motore di database per SQL Server e il database SQL di Azure non sono confrontabili tra loro e sono invece numeri di build interni per questi prodotti distinti. Il motore di database per il database SQL di Azure è basato sulla stessa codebase del motore di database di SQL Server. Soprattutto, il motore di database nel database SQL di Azure include sempre i componenti più recenti del motore di database SQL. La versione 12 del database SQL di Azure è più recente della versione 15 di SQL Server.

Procedure consigliate per aggiornare il livello di compatibilità del database

Per il flusso di lavoro consigliato per l'aggiornamento del livello di compatibilità, vedere Mantenere la stabilità delle prestazioni durante l'aggiornamento alla SQL Server più recente. Inoltre, per un'esperienza assistita con l'aggiornamento del livello di compatibilità del database, vedere Aggiornamento di database mediante l'Assistente ottimizzazione query.

Osservazioni

Per tutte le installazioni di SQL Server, il livello di compatibilità predefinito è associato alla versione del motore di database. Per i nuovi database viene impostato questo livello, a meno che per il database model non sia impostato un livello di compatibilità inferiore. Per i database collegati o ripristinati da una qualsiasi versione precedente di SQL Server, il database mantiene il livello di compatibilità esistente, se questo è almeno il livello minimo consentito per quell'istanza di SQL Server. Se si sposta un database con un livello di compatibilità inferiore a quello consentito dal motore di database, il database viene automaticamente impostato sul livello di compatibilità più basso consentito. Questo comportamento si applica sia ai database di sistema che ai database utente.

Sono previsti i comportamenti seguenti per SQL Server 2017 (14.x) quando un database viene collegato o ripristinato e dopo un aggiornamento sul posto:

  • Se il livello di compatibilità di un database utente era 100 o superiore prima dell'aggiornamento, rimane invariato dopo l'aggiornamento.
  • Se il livello di compatibilità di un database utente è 90 prima dell'aggiornamento, nel database aggiornato viene impostato su 100, ovvero sul livello di compatibilità supportato più basso in SQL Server 2017 (14.x).
  • I livelli di compatibilità dei database tempdb, model, msdb e Resource vengono impostati sul livello di compatibilità predefinito per una determinata versione del motore di database.
  • Per il database di sistema master viene mantenuto il livello di compatibilità precedente l'aggiornamento. Questo non influisce sul comportamento del database utente.

Per i database esistenti in esecuzione in livelli di compatibilità inferiori, se l'applicazione non richiede l'uso dei miglioramenti disponibili solo in un livello di compatibilità superiore, un approccio valido prevede il mantenimento del livello di compatibilità del database precedente. Per i nuovi progetti di sviluppo o quando un'applicazione esistente richiede l'uso di nuove funzionalità come l'elaborazione di query intelligenti oltre a nuovi elementi di Transact-SQL, pianificare l'aggiornamento del livello di compatibilità del database a quello più recente disponibile. Per altre informazioni, vedere Livelli di compatibilità e aggiornamenti del motore di database.

Nota

Se non sono presenti oggetti utente e dipendenze, in genere è sicuro eseguire l'aggiornamento al livello di compatibilità predefinito. Per altre informazioni, vedere Raccomandazioni - database master.

Usare ALTER DATABASE per modificare il livello di compatibilità del database. L'impostazione del nuovo livello di compatibilità per un database diventa effettiva quando si esegue un comando USE <database> o quando viene elaborato un nuovo accesso con quel database come contesto di database predefinito. Per visualizzare il livello di compatibilità corrente di un database, eseguire una query sulla colonna compatibility_level nella vista del catalogo sys.databases.

Un database di distribuzione creato in una versione precedente di SQL Server e aggiornato a SQL Server 2016 (13.x) RTM o Service Pack 1 ha il livello di compatibilità 90 che non è supportato per altri database. Ciò non determina alcun impatto sulle funzionalità di replica. L'aggiornamento ai Service Pack e alle versioni successive di SQL Server comporterà l'aumento del livello di compatibilità del database di distribuzione in modo da corrispondere a quello del master database.

Per sfruttare in generale il livello di compatibilità del database 120 o superiore, ma al tempo stesso usare il modello di stima della cardinalità di SQL Server 2012 (11.x), che corrisponde al livello di compatibilità del database 110, vedere ALTER DATABASE SCOPED CONFIGURATION e in particolare la parola chiave LEGACY_CARDINALITY_ESTIMATION = ON.

Per determinare il livello di compatibilità corrente, eseguire una query sulla colonna compatibility_level di sys.databases.

SELECT name, compatibility_level FROM sys.databases;

Osservazioni per Azure SQL database

Al mese di novembre 2019, nel database SQL di Azure il livello di compatibilità predefinito è 150 per i nuovi database. Per i database esistenti, Microsoft non aggiorna il livello di compatibilità del database. I clienti possono decidere l'approccio da adottare in base alle proprie esigenze. Microsoft consiglia di pianificare l'aggiornamento al livello di compatibilità più recente per trarre vantaggio dai miglioramenti apportati all'ottimizzazione query.

Per informazioni dettagliate su come valutare le variazioni delle prestazioni delle query più importanti tra i due diversi livelli di compatibilità nel database SQL di Azure, vedere Prestazioni delle query migliorate con il livello di compatibilità 130 in Database SQL di Azure. Questo articolo si riferisce al livello di compatibilità 130 e SQL Server, ma la stessa metodologia si applica agli aggiornamenti al livello 140 o superiori per SQL Server e il database SQL di Azure.

Per determinare la versione del motore di database a cui si è connessi, eseguire la query seguente.

SELECT SERVERPROPERTY('ProductVersion');

Non tutte le funzionalità che variano in base al livello di compatibilità sono supportate nel database SQL di Azure.

Livelli di compatibilità e aggiornamenti del motore di database

Il livello di compatibilità del database è uno strumento utile per la modernizzazione dei database poiché consente di aggiornare il motore di database di SQL Server e di preservare lo stato funzionale delle applicazioni che si connettono mantenendo lo stesso livello di compatibilità del database precedente all'aggiornamento. Ciò significa che è possibile eseguire l'aggiornamento da una versione precedente di SQL Server (ad esempio, SQL Server 2008) a SQL Server o al database SQL di Azure (incluso Istanza gestita di SQL di Azure) senza modifiche dell'applicazione (ad eccezione della connettività del database). Per altre informazioni, vedere Certificazione della compatibilità.

Se l'applicazione non richiede l'uso dei miglioramenti disponibili solo in un livello di compatibilità superiore, esso costituisce un valido approccio per aggiornare il motore di database di SQL Server e mantenere il precedente livello di compatibilità del database. Per altre informazioni sull'uso del livello di compatibilità per la compatibilità con le versioni precedenti, vedere Certificazione della compatibilità.

Livelli di compatibilità e stored procedure

Quando si esegue una stored procedure, viene usato il livello di compatibilità corrente del database in cui è definita. Se si modifica l'impostazione di compatibilità di un database, tutte le relative stored procedure vengono ricompilate automaticamente al fine di riflettere tale modifica.

Uso del livello di compatibilità per garantire la compatibilità con le versioni precedenti

L'impostazione Livello di compatibilità database garantisce la compatibilità con le versioni precedenti di SQL Server in relazione a Transact-SQL e ai comportamenti di ottimizzazione delle query solo per il database specificato, non per l'intero server.

A partire dalla modalità di compatibilità 130, tutte le nuove funzionalità e le correzioni con effetti sul piano di query sono state aggiunte intenzionalmente solo al nuovo livello di compatibilità. In questo modo si riduce al minimo il rischio che si corre durante gli aggiornamenti di ridurre il livello delle prestazioni per modifiche apportate al piano di query potenzialmente introdotte dai nuovi comportamenti di ottimizzazione query.

Dal punto di vista dell'applicazione, usare il livello di compatibilità inferiore come percorso di migrazione più sicuro per aggirare le differenze di versione, nei comportamenti controllati dall'impostazione del livello di compatibilità pertinente. L'obiettivo dovrebbe essere sempre l'aggiornamento al livello di compatibilità più recente per ereditare alcune delle nuove funzionalità come l'elaborazione di query intelligenti, il tutto eseguito però in modo controllato.

Per altri dettagli, incluso il flusso di lavoro consigliato per aggiornare il livello di compatibilità del database, vedere Procedure consigliate per aggiornare il livello di compatibilità del database.

  • Le funzionalità non più disponibili introdotte in una determinata versione di SQL Server non sono protette dal livello di compatibilità. Questo fa riferimento alle funzionalità rimosse dal motore di database di SQL Server. Ad esempio, l'hint FASTFIRSTROW non è più supportato in SQL Server 2012 (11.x) ed è stato sostituito dall'hint OPTION (FAST n ). Se il livello di compatibilità del database viene impostato su 110, l'hint che non è più supportato non viene ripristinato. Per altre informazioni sulla funzionalità interrotta, vedere Funzionalità del motore di database interrotte in SQL Server.

  • Le modifiche che causano un'interruzione introdotte in una determinata versione di SQL Server potrebbero non essere protette dal livello di compatibilità. Ciò si riferisce alle modifiche funzionali tra le versioni del motore di database di SQL Server. Il comportamento di Transact-SQL è generalmente protetto dal livello di compatibilità. Gli oggetti di sistema modificati o rimossi non sono tuttavia protetti dal livello di compatibilità.

    Un esempio di modifica di rilievo protetta dal livello di compatibilità è la conversione implicita di un tipo di dati datetime in datetime2. Con il livello di compatibilità del database 130, in questi tipi di dati si rileva una maggiore precisione prevedendo i millisecondi frazionari, risultanti in diversi valori convertiti. Per ripristinare il comportamento di conversione precedente, impostare il livello di compatibilità del database su 120 o un livello inferiore.

    Di seguito sono elencati esempi di modifiche di rilievo non protette dal livello di compatibilità:

    • Nomi di colonna modificati in oggetti di sistema. In SQL Server 2012 (11.x) la colonna single_pages_kb in sys.dm_os_sys_info è stata rinominata in pages_kb. Indipendentemente dal livello di compatibilità, la query SELECT single_pages_kb FROM sys.dm_os_sys_info genererà l'errore 207 (nome di colonna non valido).
    • Oggetti di sistema rimossi. In SQL Server 2012 (11.x) l'opzione sp_dboption è stata rimossa. Indipendentemente dal livello di compatibilità, l'istruzione EXEC sp_dboption 'AdventureWorks2016', 'autoshrink', 'FALSE'; genererà l'errore 2812 (Impossibile trovare la stored procedure 'sp_dboption').

    Per altre informazioni sulle modifiche di rilievo, vedere Modifiche di rilievo apportate alle funzionalità del motore di database in SQL Server 2019, Modifiche di rilievo apportate alle funzionalità del motore di database in SQL Server 2017, Modifiche di rilievo apportate alle funzionalità del motore di database in SQL Server 2016 e Modifiche di rilievo apportate alle funzionalità del motore di database in SQL Server 2014.

Differenze tra i livelli di compatibilità

Per tutte le installazioni di SQL Server, il livello di compatibilità predefinito è associato alla versione del motore di database, come illustrato in questa tabella. Per le nuove attività di sviluppo, pianificare sempre la certificazione delle applicazioni con il livello di compatibilità del database più recente.

La nuova sintassi di Transact-SQL non è limitata dal livello di compatibilità del database, tranne nel caso in cui interrompa le applicazioni esistenti creando un conflitto con il codice Transact-SQL dell'utente. Queste eccezioni sono documentate nelle sezioni successive di questo articolo, che illustrano le differenze tra livelli di compatibilità specifici.

Il livello di compatibilità del database garantisce anche la compatibilità con le versioni precedenti di SQL Server, perché i database collegati o ripristinati da una versione precedente di SQL Server mantengono il livello di compatibilità esistente (se uguale o superiore al livello di compatibilità minimo consentito). Questo argomento è stato illustrato nella sezione Uso del livello di compatibilità per garantire la compatibilità con le versioni precedenti di questo articolo.

A partire dal livello di compatibilità del database 130, le nuove correzioni e funzionalità che influiscono sui piani di query sono state aggiunte solo al livello di compatibilità più recente disponibile, detto anche livello di compatibilità predefinito. In questo modo si riduce al minimo il rischio che si corre durante gli aggiornamenti di ridurre il livello delle prestazioni per modifiche apportate al piano di query potenzialmente introdotte dai nuovi comportamenti di ottimizzazione query.

Le modifiche fondamentali che influiscono sul piano aggiunte solo al livello di compatibilità predefinito di una nuova versione del motore di database sono:

  1. Le correzioni di Query Optimizer rilasciate per le versioni precedenti di SQL Server con il flag di traccia 4199 diventano automaticamente abilitate nel livello di compatibilità predefinito di una versione più recente di SQL Server. Si applica a: SQL Server (a partire da SQL Server 2016 (13.x)) e Database SQL di Azure.

    Ad esempio, quando è stato rilasciato SQL Server 2016 (13.x), tutte le correzioni di Query Optimizer rilasciate per le versioni precedenti di SQL Server (e i rispettivi livelli di compatibilità da 100 a 120) sono state abilitate automaticamente per i database che usano il livello di compatibilità predefinito di SQL Server 2016 (13.x) (130). È necessario abilitare esplicitamente solo le correzioni di Query Optimizer successive alla versione RTM.

    Per abilitare le correzioni di Query Optimizer, è possibile usare i metodi seguenti:

    In un secondo momento, con il rilascio di SQL Server 2017 (14.x), tutte le correzioni di Query Optimizer rilasciate dopo la versione SQL Server 2016 (13.x) RTM sono state abilitate automaticamente per i database che usano il livello di compatibilità predefinito di SQL Server 2017 (14.x) (140). Si tratta di un comportamento cumulativo che include anche tutte le correzioni di versioni precedenti. Anche in questo caso, è necessario abilitare esplicitamente solo le correzioni di Query Optimizer successive alla versione RTM.

    Nella tabella seguente viene riepilogato questo comportamento:

    Versione del motore di database Livello di compatibilità del database TF 4199 Modifiche di Query Optimizer da tutti i livelli di compatibilità del database precedenti Modifiche di Query Optimizer per la versione del motore di database successiva alla versione RTM
    13 (SQL Server 2016 (13.x)) Da 100 a 120


    130
    Disattivato
    Attivato

    Disattivato
    Attivato
    Disabilitato
    Attivato

    Enabled
    Attivato
    Disabled
    Attivato

    Disabled
    Attivato
    14 (SQL Server 2017 (14.x)) Da 100 a 120


    130


    140
    Disattivato
    Attivato

    Disattivato
    Attivato

    Disattivato
    Attivato
    Disabilitato
    Attivato

    Enabled
    Attivato

    Enabled
    Attivato
    Disabled
    Attivato

    Disabled
    Attivato

    Disabled
    Attivato
    15 (SQL Server 2019 (15.x)) e 12 (database SQL di Azure) Da 100 a 120


    Da 130 a 140


    150
    Disattivato
    Attivato

    Disattivato
    Attivato

    Disattivato
    Attivato
    Disabilitato
    Attivato

    Enabled
    Attivato

    Enabled
    Attivato
    Disabled
    Attivato

    Disabled
    Attivato

    Disabled
    Attivato

    Le correzioni di Query Optimizer che risolvono errori di risultati non corretti o di violazione dell'accesso non sono protette dal flag di traccia 4199. Queste correzioni non sono considerate facoltative.

  2. Le modifiche apportate allo strumento di stima della cardinalità rilasciate in SQL Server e nel database SQL di Azure sono abilitate solo nel livello di compatibilità predefinito di una nuova versione del motore di database, ma non nei livelli di compatibilità precedenti.

    Ad esempio, quando è stato rilasciato SQL Server 2016 (13.x), le modifiche apportate al processo di stima della cardinalità erano disponibili solo per i database che usavano il livello di compatibilità predefinito di SQL Server 2016 (13.x) (130). I livelli di compatibilità precedenti conservavano il comportamento di stima della cardinalità disponibile prima di SQL Server 2016 (13.x).

    Successivamente, quando è stato rilasciato SQL Server 2017 (14.x), le modifiche apportate al processo di stima della cardinalità erano disponibili solo per i database che usavano il livello di compatibilità predefinito di SQL Server 2017 (14.x) (140). Il livello di compatibilità del database 130 ha conservato il comportamento di stima della cardinalità di SQL Server 2016 (13.x).

    Nella tabella seguente viene riepilogato questo comportamento:

    Versione del motore di database Livello di compatibilità del database Modifiche nuova versione strumento di stima della cardinalità
    13 (SQL Server 2016 (13.x)) < 130
    130
    Disabled
    Attivato
    14 (SQL Server 2017 (14.x))1 < 140
    140
    Disabled
    Attivato
    15 (SQL Server 2019 (15.x))1 < 150
    150
    Disabled
    Attivato
    16 (SQL Server 2022 (anteprima 16.x) 1 < 160
    160
    Disabled
    Attivato

    1 Applicabile anche al database SQL di Azure.

Altre differenze tra i livelli di compatibilità specifici sono descritte nelle sezioni successive di questo articolo.

Differenze tra il livello di compatibilità 150 e il livello 160

Questa sezione descrive nuovi comportamenti introdotti con il livello di compatibilità 160.

Impostazione del livello di compatibilità di 150 o inferiore Impostazione del livello di compatibilità 160
Le query con parametri hanno un singolo piano di query in base ai parametri usati per la prima esecuzione. Solo un piano di query viene memorizzato nella cache e usato per tutti i valori dei parametri. Ciò può causare un piano di query inefficiente per alcuni valori del parametro, noto anche come piano sensibile ai parametri. Le query con parametri possono avere più piani di query memorizzati nella cache per categorie di selezione diverse di un parametro. L'ottimizzazione del piano sensibile ai parametri è abilitata per impostazione predefinita nel livello di compatibilità 160. Per altre informazioni, vedere Ottimizzazione PSP.
La stima della cardinalità usa un solo set predefinito di presupposti del modello relativi alla distribuzione e ai modelli di utilizzo dei dati sottostanti per tutti i database e le query. L'unico modo per modificare o modificare uno di questi presupposti è quando l'utente esegue un processo manuale per indicare in modo esplicito quali presupposti del modello devono essere usati, tramite l'uso di hint di query. Non è possibile apportare modifiche interne a questo modello predefinito dopo la generazione di un piano di query. La stima della cardinalità inizia con il set predefinito di presupposti del modello sui modelli di distribuzione e utilizzo dei dati sottostanti, ma dopo un determinato numero di esecuzioni per una determinata query, il motore di database apprende quali diversi set di presupposti del modello potrebbero produrre stime più accurate e quindi modifica i presupposti in uso per corrispondere meglio al set di dati sottoposto a query. Il feedback CE è abilitato per impostazione predefinita nel livello di compatibilità 160. Per altre informazioni, vedere Feedback CE.
Nessuna determinazione automatica del grado ottimale di parallelismo viene tentato dal motore di database. Per informazioni sul controllo manuale del grado massimo di parallelismo (MAXDOP) a livello di istanza, database, query o carico di lavoro, vedere Configurare il grado massimo di parallelism Server Configuration Option Il grado di parallelismo (DOP) migliora le prestazioni delle query identificando l'inefficienze parallelismo per ripetere le query, in base al tempo trascorso e alle attese. Se l'utilizzo del parallelismo è considerato inefficiente, il feedback DOP ridurrà il DOP per l'esecuzione successiva della query, da qualsiasi cosa sia il DOP configurato e verificare se è utile. Il feedback DOP non è abilitato per impostazione predefinita. Per abilitare feedback DOP, abilitare la DOP_FEEDBACK configurazione con ambito del database in un database. Per altre informazioni, vedere Feedback DOP.

Differenze tra i livelli di compatibilità 140 e 150

In questa sezione vengono descritti i nuovi comportamenti introdotti con il livello di compatibilità 150.

Livello di compatibilità 140 o inferiore Livello di compatibilità 150
I carichi di lavoro analitici e per data warehouse relazionali potrebbero non essere in grado di sfruttare gli indici columnstore a causa dell'overhead OLTP, della mancanza di supporto dei fornitori o di altre limitazioni. Senza gli indici columnstore, questi carichi di lavoro non possono trarre vantaggio dalla modalità di esecuzione batch. La modalità di esecuzione batch è ora disponibile per i carichi di lavoro analitici senza richiedere indici columnstore. Per altre informazioni, vedere Modalità batch per rowstore.
Le query in modalità riga per le quali sono necessarie concessioni di memoria di dimensioni insufficienti che causano distribuzioni su disco possono essere problematiche su esecuzioni consecutive. Le query in modalità riga per le quali sono necessarie concessioni di memoria di dimensioni insufficienti che causano distribuzioni su disco possono evidenziare miglioramenti in termini di prestazioni su esecuzioni consecutive. Per altre informazioni, vedere Feedback sulla concessione della memoria in modalità riga.
Le query in modalità riga per le quali sono necessarie concessioni di memoria di dimensioni eccessive che causano problemi di concorrenza possono essere problematiche su esecuzioni consecutive. Le query in modalità riga per le quali sono necessarie concessioni di memoria di dimensioni eccessive che causano problemi di concorrenza possono evidenziare miglioramenti in termini di concorrenza su esecuzioni consecutive. Per altre informazioni, vedere Feedback sulla concessione della memoria in modalità riga.
Le query che fanno riferimento a funzioni definite dall'utente scalari T-SQL useranno la chiamata iterativa, senza calcolo dei costi e con esecuzione seriale imposta. Le funzioni definite dall'utente scalari T-SQL vengono trasformate in espressioni relazionali equivalenti che vengono "rese inline" nella query chiamante, ottenendo spesso significativi miglioramenti delle prestazioni. Per altre informazioni, vedere Inlining di funzioni definite dall'utente scalari T-SQL.
Le variabili di tabella usano un'ipotesi fissa per la stima della cardinalità. Se il numero effettivo di righe è molto superiore al valore ipotizzato, possono esserci effetti negativi sulle prestazioni delle operazioni downstream. I nuovi piani useranno la cardinalità effettiva della variabile tabella rilevata nella prima compilazione invece di una stima fissa. Per altre informazioni, vedere Compilazione posticipata delle variabili di tabella.

Per altre informazioni sulle funzionalità di elaborazione delle query abilitate nel livello di compatibilità del database 150, vedere Novità di SQL Server 2019 ed Elaborazione di query intelligenti nei database SQL.

Differenze tra i livelli di compatibilità 130 e 140

In questa sezione vengono descritti i nuovi comportamenti introdotti con il livello di compatibilità 140.

Livello di compatibilità 130 o inferiore Livello di compatibilità 140
Le stime della cardinalità per istruzioni che fanno riferimento a funzioni composte da più istruzioni con valori di tabella usano un'ipotesi a riga fissa. Le stime della cardinalità per istruzioni idonee che fanno riferimento a funzioni composte da più istruzioni con valori di tabella usano la cardinalità effettiva dell'output della funzione. Questo comportamento è abilitato dall'esecuzione interleaved per funzioni composte da più istruzioni con valori di tabella.
Le query in modalità batch per le quali sono necessarie concessioni di memoria di dimensioni insufficienti che causano distribuzioni su disco possono essere problematiche su esecuzioni consecutive. Le query in modalità batch per le quali sono necessarie concessioni di memoria di dimensioni insufficienti che causano distribuzioni su disco possono evidenziare miglioramenti in termini di prestazioni su esecuzioni consecutive. Questo comportamento è abilitato tramite i commenti della concessione di memoria della modalità batch che aggiornerà le dimensioni della concessione di memoria di un piano memorizzato nella cache se si sono verificate distribuzioni per gli operatori della modalità batch.
Le query in modalità batch per le quali sono necessarie concessioni di memoria di dimensioni eccessive che causano problemi di concorrenza possono essere problematiche su esecuzioni consecutive. Le query in modalità batch per le quali sono necessarie concessioni di memoria di dimensioni eccessive che causano problemi di concorrenza possono evidenziare miglioramenti in termini di concorrenza su esecuzioni consecutive. Questo comportamento è abilitato tramite i commenti della concessione di memoria della modalità batch che aggiornerà le dimensioni della concessione di memoria di un piano memorizzato nella cache se inizialmente era richiesta una memoria di dimensioni eccessive.
Le query in modalità batch contenenti operatori di join sono idonee per tre algoritmi di join fisico, tra cui join annidato dei cicli, hash join e merge join. Se le stime della cardinalità non sono corrette per gli input di join, può essere selezionato un algoritmo di join non appropriato. In questo caso le prestazioni ne risentiranno e l'algoritmo di join non appropriato rimarrà in uso fino alla ricompilazione del piano memorizzato nella cache. Esiste un operatore di join aggiuntivo denominato join adattivo. Se le stime della cardinalità non sono corrette per l'input dell'outer join di compilazione, può essere selezionato un algoritmo di join non appropriato. In questo caso e se l'istruzione è idonea per un join adattivo, verranno usati in modo dinamico un join annidato dei cicli per gli input di join più piccoli e un hash join per gli input di join più grandi senza richiedere la ricompilazione.
I piani semplici che fanno riferimento agli indici Columnstore non sono idonei per l'esecuzione in modalità batch. Un piano semplice che fa riferimento agli indici Columnstore sarà eliminato e sostituito da un piano idoneo per l'esecuzione in modalità batch.
L'operatore UDX sp_execute_external_script può essere eseguito solo in modalità riga. L'operatore UDX sp_execute_external_script è idoneo per l'esecuzione in modalità batch.
Le funzioni con valori di tabella composte da più istruzioni non presentano un'esecuzione interleaved Esecuzione interleaved per funzioni con valori di tabella con istruzioni multiple per migliorare la qualità del piano.

Le correzioni nel flag di traccia 4199 delle versioni precedenti di SQL Server precedenti a SQL Server 2017 sono ora abilitate per impostazione predefinita. Con la modalità di compatibilità 140, il flag di traccia 4199 continuerà a essere applicabile alle nuove correzioni di Query Optimizer rilasciate dopo SQL Server 2017. Per informazioni sul flag di traccia 4199, vedere Flag di traccia 4199.

Differenze tra i livelli di compatibilità 120 e 130

In questa sezione vengono descritti i nuovi comportamenti introdotti con il livello di compatibilità 130.

Livello di compatibilità 120 o inferiore Livello di compatibilità 130
INSERT in un'istruzione INSERT-SELECT è a thread singolo. INSERT in un'istruzione INSERT-SELECT è multithread o può avere un piano parallelo.
Le query in una tabella ottimizzata per la memoria vengono eseguite a thread singolo. Le query in una tabella ottimizzata per la memoria ora possono avere piani paralleli.
Introduzione della stima di cardinalità di SQL 2014 CardinalityEstimationModelVersion="120" Miglioramenti della stima di cardinalità grazie al modello di stima di cardinalità 130, visibile da un piano di query. CardinalityEstimationModelVersion="130"
Modifiche in modalità batch e modifiche in modalità riga con indici Columnstore:
  • Gli ordinamenti in una tabella con indice Columnstore sono in modalità riga
  • Le aggregazioni di funzioni finestra sono usate in modalità riga, ad esempio LAG o LEAD
  • Le query su tabelle Columnstore con più clausole Distinct sono usate in modalità riga
  • Le query in esecuzione con MAXDOP 1 o con un piano seriale sono usate in modalità riga
Modifiche in modalità batch e modifiche in modalità riga con indici Columnstore:
  • Gli ordinamenti in una tabella con indice Columnstore sono ora in modalità riga
  • Le aggregazioni di funzioni finestra sono ora usate in modalità batch, ad esempio LAG o LEAD
  • Le query su tabelle Columnstore con più clausole Distinct sono usate in modalità batch
  • Le query in esecuzione con MAXDOP 1 o con un piano seriale vengono eseguite in modalità batch
Le statistiche vengono aggiornate automaticamente. La logica su cui si basa l'aggiornamento automatico delle statistiche è più aggressiva in tabelle di grandi dimensioni. In pratica, si dovrebbero ridurre i casi in cui i clienti registrano problemi di prestazioni in termini di quey laddove le righe appena inserite vengono frequentemente sottoposte a query senza però che le statistiche siano state ancora aggiornate con i valori attuali.
La traccia 2371 è OFF per impostazione predefinita in SQL Server 2014 (12.x). La traccia 2371 è ON per impostazione predefinita in SQL Server 2016 (13.x). Il flag di traccia 2371 indica allo strumento di aggiornamento delle statistiche automatico di prendere come esempio un subset di righe più piccolo ma più idoneo, in una tabella con un elevato numero di righe.

Al fine di un miglioramento, è possibile includere nell'esempio più righe rispetto a quelle che sono state inserite di recente.

Un altro miglioramento prevede di eseguire le query, anziché bloccarle, nello stesso momento in cui viene eseguito il processo di aggiornamento delle statistiche.
Per il livello 120, le statistiche vengono campionate da un processo a thread singolo. Per il livello 130, le statistiche vengono campionate da un processo multithread (processo parallelo).
253 è il limite di chiavi esterne in ingresso. A una tabella possono fare riferimento fino a 10.000 chiavi esterne in ingresso o riferimenti simili. Per informazioni sulle restrizioni, vedere Create Foreign Key Relationships.
Gli algoritmi di join hash MD2, MD4, MD5, SHA e SHA1 sono consentiti. Sono consentiti solo gli algoritmi di join hash SHA2_256 e SHA2_512.
SQL Server 2016 (13.x) include miglioramenti in alcune conversioni di tipi di dati e alcune operazioni (in genere non comuni). Per informazioni dettagliate, vedere Miglioramenti di SQL Server 2016 relativi alla gestione di alcuni tipi di dati e operazioni non comuni.
La funzione STRING_SPLIT non è disponibile. La funzione STRING_SPLIT è disponibile nel livello di compatibilità 130 o superiore. Se il livello di compatibilità del database è inferiore a 130, SQL Server non sarà in grado di trovare ed eseguire la funzione STRING_SPLIT.

Le correzioni nel flag di traccia 4199 delle versioni meno recenti di SQL Server precedenti a SQL Server 2016 (13.x) sono ora abilitate per impostazione predefinita. Con la modalità di compatibilità 130, il flag di traccia 4199 continuerà a essere applicabile alle nuove correzioni di Query Optimizer rilasciate dopo SQL Server 2016 (13.x). Per usare la versione precedente di Query Optimizer nel database SQL è necessario selezionare il livello di compatibilità 110. Per informazioni sul flag di traccia 4199, vedere Flag di traccia 4199.

Differenze tra i livelli di compatibilità inferiori e il livello 120

Questa sezione descrive i nuovi comportamenti introdotti con il livello di compatibilità 120.

Livello di compatibilità 110 o inferiore Livello di compatibilità 120
Viene utilizzata la versione precedente di Query Optimizer. SQL Server 2014 (12.x) include miglioramenti sostanziali al componente per la creazione e l'ottimizzazione dei piani di query. Questa nuova funzionalità di Query Optimizer dipende dall'utilizzo del livello di compatibilità del database 120. Per sfruttare al meglio questi miglioramenti, sarebbe opportuno sviluppare le nuove applicazioni di database utilizzando il livello di compatibilità del database 120. Le applicazioni di cui si esegue la migrazione da versioni precedenti di SQL Server devono essere testate con attenzione per assicurarsi che le prestazioni vengano mantenute o migliorate. Se si verifica un calo delle prestazioni, è possibile impostare il livello di compatibilità del database su 110 o su un valore inferiore per utilizzare la metodologia precedente di Query Optimizer.

Il livello di compatibilità 120 del database utilizza un nuovo strumento di stima della cardinalità ottimizzato per i carichi di lavoro OLTP e di data warehouse più recenti. Prima di impostare il livello di compatibilità del database su 110 a causa di problemi di prestazioni, vedere le indicazioni riportate nella sezione Piani di query dell'articolo Novità del motore di database di SQL Server 2014 (12.x).
Nei livelli di compatibilità inferiori a 120, l'impostazione della lingua viene ignorata durante la conversione di un valore date in un valore stringa. Si noti che questo comportamento è specifico solo del tipo date. Vedere l'esempio B nella sezione Esempi riportata più avanti. L'impostazione della lingua non viene ignorata durante la conversione di un valore date in un valore stringa.
I riferimenti ricorsivi a destra di una clausola EXCEPT creano un ciclo infinito. L'esempio C nella sezione Esempi riportata più avanti illustra questo comportamento. I riferimenti ricorsivi in una clausola EXCEPT generano un errore in conformità allo standard ANSI SQL.
L'espressione di tabella comune (CTE) ricorsiva consente l'uso di nomi colonna duplicati. Una CTE ricorsiva non consente nomi di colonna duplicati.
I trigger disabilitati vengono abilitati se i trigger vengono modificati. La modifica di un trigger non cambia lo stato (abilitato o disabilitato) del trigger.
La clausola della tabella OUTPUT INTO ignora IDENTITY_INSERT SETTING = OFF e consente l'inserimento di valori espliciti. Non è possibile inserire valori espliciti per un colonna Identity in una tabella se IDENTITY_INSERT è impostato su OFF.
Quando il contenimento del database è impostato su parziale, la convalida del campo $action nella clausola OUTPUT di un'istruzione MERGE può restituire un errore nelle regole di confronto. Le regole di confronto dei valori restituiti dalla clausola $action di un'istruzione MERGE sono le regole di confronto del database anziché le regole di confronto del server e non viene restituito alcun errore di conflitto tra regole di confronto.
Tramite un'istruzione SELECT INTO viene sempre creata un'operazione di inserimento a thread singolo. Tramite un'istruzione SELECT INTO è possibile creare un'operazione di inserimento parallela. Quando si inserisce un numero elevato di righe, con un'operazione parallela è possibile migliorare le prestazioni.

Differenze tra i livelli di compatibilità inferiori e i livelli 100 e 110

Questa sezione descrive i nuovi comportamenti introdotti con il livello di compatibilità 110. Questa sezione si applica anche ai livelli di compatibilità superiori a 110.

Livello di compatibilità 100 o inferiore Impostazione del livello di compatibilità 110 o inferiore
Gli oggetti di database CLR (Common Language Runtime) vengono eseguiti con la versione 4 di CLR. Non sono tuttavia presenti alcune modifiche del comportamento introdotte con la versione 4 di CLR. Per altre informazioni, vedere Novità dell'integrazione CLR. Gli oggetti di database CLR vengono eseguiti con la versione 4 di CLR.
Le funzioni XQuery string-length e substring considerano ogni surrogato come due caratteri. Le funzioni XQuery string-length e substring considerano ogni surrogato come un carattere.
La parola chiave PIVOT è consentita in una query ricorsiva dell'espressione di tabella comune. La query tuttavia restituisce risultati non corretti quando sono presenti più righe per raggruppamento. La parola chiave PIVOT non è consentita in una query ricorsiva dell'espressione di tabella comune (CTE). Viene restituito un errore.
L'algoritmo RC4 è supportato solo per motivi di compatibilità con le versioni precedenti. È possibile crittografare il nuovo materiale usando RC4 o RC4_128 solo quando il livello di compatibilità del database è 90 o 100. (Non consigliato.) In SQL Server 2012 (11.x) il materiale crittografato usando RC4 o RC4_128 può essere decrittografato in qualsiasi livello di compatibilità. Il nuovo materiale non può essere crittografato usando RC4 o RC4_128. Usare un algoritmo più recente, ad esempio uno degli algoritmi AES. In SQL Server 2012 (11.x) il materiale crittografato usando RC4 o RC4_128 può essere decrittografato in qualsiasi livello di compatibilità.
Lo stile predefinito per le operazioni CAST e CONVERT sui tipi di dati time e datetime2 è 121, tranne quando uno dei due tipi viene usato in un'espressione della colonna calcolata. Per le colonne calcolate, lo stile predefinito è 0. Questo comportamento influisce sulle colonne calcolate quando vengono create o usate nelle query con parametrizzazione automatica o nelle definizioni dei vincoli.

L'esempio D nella sezione Esempi riportata più avanti illustra la differenza tra gli stili 0 e 121. Non viene illustrato il comportamento descritto sopra. Per altre informazioni sugli stili di data e ora, vedere CAST e CONVERT.
Con il livello di compatibilità 110, lo stile predefinito per CAST e CONVERT sui tipi di dati time e datetime2 è sempre 121. Se la query si basa sul comportamento obsoleto, usare un livello di compatibilità inferiore a 110 oppure specificare in modo esplicito lo stile 0 nella query interessata.

L'aggiornamento del database al livello di compatibilità 110 non comporta la modifica dei dati utente archiviati su disco. È necessario correggere manualmente questi dati nel modo opportuno. Se ad esempio si usa SELECT INTO per creare una tabella da un'origine che contiene un'espressione della colonna calcolata descritta in precedenza, verranno archiviati i dati (con stile 0), anziché la definizione della colonna calcolata. Sarà necessario aggiornare manualmente questi dati in base allo stile 121.
L'operatore + (Addizione) può essere applicato a un operando di tipo date, time, datetime2 o datetimeoffset se l'altro operando ha il tipo datetime o smalldatetime. Il tentativo di applicare l'operatore addizione a un operando di tipo date, time, datetime2 o datetimeoffset e un operando di tipo datetime o smalldatetime genererà l'errore 402.
Per tutte le colonne delle tabelle remote di tipo smalldatetime a cui viene fatto riferimento in una vista partizionata viene eseguito il mapping come datetime. Le colonne corrispondenti delle tabelle locali, ovvero le colonne che occupano la stessa posizione ordinale nell'elenco di selezione, devono essere di tipo datetime. Per tutte le colonne delle tabelle remote di tipo smalldatetime a cui viene fatto riferimento in una vista partizionata viene eseguito il mapping come smalldatetime. Le colonne corrispondenti delle tabelle locali, ovvero le colonne che occupano la stessa posizione ordinale nell'elenco di selezione, devono essere di tipo smalldatetime.

Dopo aver effettuato l'aggiornamento al livello di compatibilità 110, la vista partizionata distribuita avrà esito negativo poiché i tipi di dati non corrisponderanno. È possibile risolvere questo problema impostando il tipo di dati nella tabella remota su datetime o impostando il livello di compatibilità del database locale su 100 o su un valore inferiore.
Tramite la funzione SOUNDEX vengono implementate le regole seguenti:

1) La H o W maiuscola viene ignorata se separa due consonanti aventi lo stesso numero nel codice SOUNDEX.

2) Se il numero dei primi 2 caratteri di character_expression è uguale nel codice SOUNDEX, entrambi i caratteri vengono inclusi. Altrimenti, se il numero di un set di consonanti affiancate è uguale nel codice SOUNDEX, vengono escluse tutte le consonanti eccetto la prima.
Tramite la funzione SOUNDEX vengono implementate le regole seguenti:

1) Se la H o W maiuscola separa due consonanti aventi lo stesso numero nel codice SOUNDEX, la consonante a destra viene ignorata

2) Se il numero di un set di consonanti affiancate è uguale nel codice SOUNDEX, vengono escluse tutte le consonanti eccetto la prima.



Le regole aggiuntive potrebbero generare una differenza tra i valori calcolati dalla funzione SOUNDEX e quelli calcolati con livelli di compatibilità precedenti. Dopo aver eseguito l'aggiornamento al livello di compatibilità 110, potrebbe essere necessario ricompilare gli indici, gli heap o i vincoli CHECK in cui viene usata la funzione SOUNDEX. Per altre informazioni, vedere SOUNDEX.
L'istruzione STRING_AGG è disponibile senza una clausola <order_clause>. L'istruzione STRING_AGG è disponibile con una clausola <order_clause> facoltativa. Per altre informazioni, vedere STRING_AGG

Differenze tra i livelli di compatibilità 90 e 100

In questa sezione vengono descritti i nuovi comportamenti introdotti con il livello di compatibilità 100.

Livello di compatibilità 90 Livello di compatibilità 100 Probabilità di impatto
L'impostazione QUOTED_IDENTIFER è sempre impostata su ON per le funzioni con valori di tabella composte da più istruzioni quando tali funzioni vengono create indipendentemente dall'impostazione del livello di sessione. L'impostazione della sessione QUOTED IDENTIFIER viene applicata quando vengono create funzioni con valori di tabella composte da più istruzioni. Media
Quando si crea o si modifica una funzione di partizione, i valori letterali datetime e smalldatetime nella funzione vengono valutati presupponendo che l'impostazione della lingua sia US_English. L'impostazione della lingua corrente viene usata per valutare i valori letterali datetime e smalldatetime nella funzione di partizione. Media
La clausola FOR BROWSE è consentita (e ignorata) nelle istruzioni INSERT e SELECT INTO. La clausola FOR BROWSE non è consentita nelle istruzioni INSERT e SELECT INTO. Media
Nella clausola OUTPUT sono consentiti predicati full-text. Nella clausola OUTPUT non sono consentiti predicati full-text. Basso
CREATE FULLTEXT STOPLIST, ALTER FULLTEXT STOPLIST e DROP FULLTEXT STOPLIST non sono supportate. Per impostazione predefinita, ai nuovi indici full-text viene associato automaticamente l'elenco di parole non significative di sistema. Le istruzioni CREATE FULLTEXT STOPLIST, ALTER FULLTEXT STOPLIST e DROP FULLTEXT STOPLIST sono supportate. Basso
L'istruzione MERGE non viene imposta come parola chiave riservata. MERGE è una parola chiave completamente riservata. L'istruzione MERGE è supportata con i livelli di compatibilità 100 e 90. Basso
Se si usa l'argomento <dml_table_source> dell'istruzione INSERT, viene generato un errore di sintassi. È possibile acquisire i risultati di una clausola OUTPUT in un'istruzione INSERT, UPDATE, DELETE o MERGE nidificata e inserire tali risultati in una vista o tabella di destinazione. A tale scopo, usare l'argomento <dml_table_source> dell'istruzione INSERT. Basso
A meno che non sia specificato NOINDEX, DBCC CHECKDB o DBCC CHECKTABLE esegue controlli di consistenza sia fisica sia logica in una singola tabella o vista indicizzata e in tutti i relativi indici non cluster e XML. Gli indici spaziali non sono supportati. A meno che non sia specificato NOINDEX, DBCC CHECKDB o DBCC CHECKTABLE esegue controlli di consistenza sia fisica sia logica in una singola tabella e in tutti i relativi indici non cluster. Per impostazione predefinita, tuttavia, negli indici XML, negli indici spaziali e nelle viste indicizzate vengono eseguiti solo controlli di consistenza fisica.

Se è specificato WITH EXTENDED_LOGICAL_CHECKS, vengono eseguiti controlli logici su viste indicizzate, indici XML e indici spaziali, laddove presenti. Per impostazione predefinita, i controlli di consistenza fisica vengono eseguiti prima di quelli di consistenza logica. Se viene specificato anche NOINDEX, vengono eseguiti solo i controlli logici.
Basso
Quando una clausola OUTPUT viene utilizzata con un'istruzione DML (Data Manipulation Language) e si verifica un errore di run-time durante l'esecuzione di istruzioni, l'intera transazione viene terminata e ne viene eseguito il rollback. Quando una clausola OUTPUT viene usata con un'istruzione DML (Data Manipulation Language) e si verifica un errore di runtime durante l'esecuzione delle istruzioni, il comportamento dipende dall'impostazione di SET XACT_ABORT. Se SET XACT_ABORT è impostato su OFF, un errore di interruzione dell'istruzione generato dall'istruzione DML tramite la clausola OUTPUT terminerà l'istruzione, ma l'esecuzione del batch continuerà e non verrà eseguito il rollback della transazione. Se SET XACT_ABORT è impostato su ON, tutti gli errori di runtime generati dall'istruzione DML tramite la clausola OUTPUT termineranno il batch e verrà eseguito il rollback della transazione. Basso
CUBE e ROLLUP non vengono applicate come parole chiave riservate. CUBE e ROLLUP sono parole chiave riservate all'interno della clausola GROUP BY. Basso
Agli elementi del tipo anyType XML viene applicata una convalida di tipo strict. Agli elementi del tipo anyType viene applicata una convalida di tipo lax. Per altre informazioni, vedere Componenti jolly e convalida del contenuto. Basso
Non è possibile eseguire query sugli attributi speciali xsi:nil e xsi:type, né modificarli tramite istruzioni DML.

Di conseguenza, /e/@xsi:nil ha esito negativo, mentre /e/@* ignora gli attributi xsi:nil e xsi:type. /e restituisce tuttavia gli attributi xsi:nil e xsi:type per la consistenza con SELECT xmlCol, anche se xsi:nil = "false".
Gli attributi speciali xsi:nil e xsi:type vengono archiviati come attributi regolari e possono essere sottoposti a query o modificati.

L'esecuzione della query SELECT x.query('a/b/@*') restituisce ad esempio tutti gli attributi, inclusi xsi:nil e xsi:type. Per escludere questi tipi nella query, sostituire @* con @*[namespace-uri(.) != "insert xsi namespace uri" e non (local-name(.) = "type" o local-name(.) ="nil".
Basso
Una funzione definita dall'utente che converte un valore stringa costante XML in un tipo datetime di SQL Server viene contrassegnata come deterministica. Una funzione definita dall'utente che converte un valore stringa costante XML in un tipo datetime di SQL Server viene contrassegnata come non deterministica. Basso
I tipi unione ed elenco XML non sono supportati completamente. I tipi unione ed elenco sono supportati completamente, incluse le funzionalità seguenti.

Unione di elenco

Unione di unione

Elenco di tipi atomici

Elenco di unione
Basso
Le opzioni SET necessarie per un metodo xQuery non vengono convalidate quando il metodo è contenuto in una vista o in una funzione con valori di tabella inline. Le opzioni SET necessarie per un metodo xQuery vengono convalidate quando il metodo è contenuto in una vista o in una funzione inline con valori di tabella. Se le opzioni SET del metodo non sono impostate correttamente, viene generato un errore. Basso
I valori di attributo XML contenenti caratteri di fine riga (ritorno a capo e avanzamento riga) non vengono normalizzati in base allo standard XML, ovvero vengono restituiti entrambi i caratteri anziché un singolo carattere di avanzamento riga. I valori di attributo XML contenenti caratteri di fine riga (ritorno a capo e avanzamento riga) vengono normalizzati in base allo standard XML, ovvero tutte le interruzioni di riga in entità analizzate esterne (inclusa l'entità del documento) vengono normalizzate in fase di input traducendo sia la sequenza di due caratteri #xD #xA sia qualsiasi carattere #xD non seguito da #XA in un singolo carattere #xA.

Le applicazioni che utilizzano attributi per trasportare valori stringa contenenti caratteri di fine riga non riceveranno di nuovo tali caratteri quando questi vengono inviati. Per evitare il processo di normalizzazione, utilizzare entità di caratteri numerici XML per codificare tutti i caratteri di fine riga.
Basso
Le proprietà di colonna ROWGUIDCOL e IDENTITY possono essere erroneamente denominate come vincolo. L'istruzione CREATE TABLE T (C1 int CONSTRAINT MyConstraint IDENTITY), ad esempio, viene eseguita correttamente, ma il nome del vincolo non viene mantenuto e non è accessibile per l'utente. Le proprietà di colonna ROWGUIDCOL e IDENTITY non possono essere denominate come vincolo. In caso contrario, verrà restituito l'errore 156. Basso
L'aggiornamento di colonne con un'assegnazione bidirezionale, ad esempio UPDATE T1 SET @v = column_name = <expression>, può produrre risultati imprevisti, poiché è possibile che durante l'esecuzione dell'istruzione in altre clausole, ad esempio WHERE e ON, venga usato il valore attivo della variabile anziché il valore iniziale dell'istruzione. Ciò può comportare una modifica imprevista dei significati dei predicati per ciascuna riga.

Questo comportamento è applicabile solo quando il livello di compatibilità è impostato su 90.
L'aggiornamento di colonne tramite un'assegnazione bidirezionale produce i risultati previsti, in quanto durante l'esecuzione dell'istruzione è possibile accedere solo al valore iniziale dell'istruzione per la colonna. Basso
L'assegnazione di variabile è consentita in un'istruzione contenente un operatore UNION di livello principale, ma restituisce risultati imprevisti. Per altre informazioni, vedere l'esempio E. L'assegnazione di variabile non è consentita in un'istruzione contenente un operatore UNION di livello principale. In caso contrario, verrà restituito l'errore 10734. Cercare una riscrittura suggerita nell'esempio E. Basso
La funzione ODBC {fn CONVERT()} utilizza il formato di data predefinito della lingua specifica. Per alcune lingue il formato predefinito è AGM, che può comportare errori di conversione quando la funzione CONVERT() è combinata con altre funzioni, ad esempio {fn CURDATE()}, che prevedono l'uso del formato AMG. La funzione ODBC {fn CONVERT()} usa lo stile 121, un formato AMG indipendente dalla lingua, per la conversione nei tipi di dati ODBC SQL_TIMESTAMP, SQL_DATE, SQL_TIME, SQLDATE, SQL_TYPE_TIME e SQL_TYPE_TIMESTAMP. Basso
Le funzioni intrinseche datetime, ad esempio DATEPART, non richiedono che i valori di input di tipo stringa siano valori letterali datetime validi. Ad esempio, SELECT DATEPART (year, '2007/05-30') viene compilato correttamente. Le funzioni intrinseche datetime, ad esempio DATEPART, richiedono che i valori di input di tipo stringa siano valori letterali datetime validi. Quando si utilizza un valore letterale datetime non valido, viene restituito l'errore 241. Basso
Gli spazi finali specificati nel primo parametro di input per la funzione REPLACE vengono eliminati quando il parametro è di tipo char. Ad esempio, nell'istruzione SELECT '<' + REPLACE(CONVERT(char(6), 'ABC '), ' ', 'L') + '>', il valore 'ABC ' viene erroneamente valutato come 'ABC'. Gli spazi finali vengono sempre mantenuti. Per le applicazioni che si basano sul comportamento precedente della funzione, usare la funzione RTRIM quando si specifica il primo parametro di input per la funzione. La sintassi seguente, ad esempio, riproduce il comportamento di SQL Server 2005 SELECT '<' + REPLACE(RTRIM(CONVERT(char(6), 'ABC ')), ' ', 'L') + '>'. Basso

Parole chiave riservate

L'impostazione di compatibilità determina anche le parole chiave riservate dal motore di database. Nella tabella seguente sono elencate le parole chiave riservate introdotte per ogni livello di compatibilità.

Livello di compatibilità Parole chiave riservate
130 Da determinare.
120 No.
110 WITHIN GROUP, TRY_CONVERT, SEMANTICKEYPHRASETABLE, SEMANTICSIMILARITYDETAILSTABLE, SEMANTICSIMILARITYTABLE
100 CUBE, MERGE, ROLLUP
90 EXTERNAL, PIVOT, UNPIVOT, REVERT, TABLESAMPLE

A un determinato livello di compatibilità, le parole chiave riservate includono tutte le parole chiave introdotte per tale livello e per quelli precedenti. Pertanto, ad esempio, per le applicazioni con livello 110 tutte le parole chiave elencate nella tabella precedente sono parole chiave riservate. Per i livelli di compatibilità inferiori, le parole chiave del livello 100 rimangono nomi di oggetti validi ma le funzionalità del linguaggio di livello 110 corrispondenti a tale parole chiave non sono disponibili.

Una volta introdotta, una parola chiave rimane riservata. La parola chiave riservata PIVOT, ad esempio, introdotta per il livello di compatibilità 90, è riservata per i livelli 100, 110 e 120.

Se per un'applicazione si utilizza un identificatore che rappresenta una parola chiave riservata nel livello di compatibilità relativo, viene generato un errore. In alternativa, racchiudere l'identificatore tra parentesi quadre ( [] ) o virgolette ( "" ). Per aggiornare ad esempio un'applicazione che usa l'identificatore EXTERNAL al livello di compatibilità 90, è possibile modificare l'identificatore in [EXTERNAL] o "EXTERNAL".

Per altre informazioni, vedere Parole chiave riservate.

Autorizzazioni

È richiesta l'autorizzazione ALTER per il database.

Esempi

R. Modificare il livello di compatibilità

Nell'esempio seguente il livello di compatibilità del database di esempioAdventureWorks2019 viene modificato e impostato su 150, il valore predefinito per SQL Server 2019 (15.x).

ALTER DATABASE AdventureWorks2019
SET COMPATIBILITY_LEVEL = 150;
GO

Nell'esempio seguente viene restituito il livello di compatibilità del database corrente.

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

B. L'istruzione SET LANGUAGE viene ignorata tranne che nel livello di compatibilità 120 o successivo

La query seguente ignora l'istruzione SET LANGUAGE tranne che nel livello di compatibilità 120 o superiore.

SET DATEFORMAT dmy;
DECLARE @t2 date = '12/5/2011' ;
SET LANGUAGE dutch;
SELECT CONVERT(varchar(11), @t2, 106);
GO

Risultati quando il livello di compatibilità è minore di 120: 12 May 2011

Risultati quando il livello di compatibilità è impostato su 120 o superiore: 12 mei 2011

C. Per il livello di compatibilità impostato su 110 o un valore inferiore, i riferimenti ricorsivi a destra di una clausola EXCEPT creano un ciclo infinito

WITH cte AS 
    (SELECT * FROM (VALUES (1),(2),(3)) 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. La differenza tra gli stili 0 e 121

Quando il livello di compatibilità è inferiore a 110, lo stile predefinito per le operazioni CAST e CONVERT sui tipi di dati time e datetime2 è 121, tranne quando uno dei due tipi viene usato in un'espressione di colonna calcolata. Per le colonne calcolate, lo stile predefinito è 0.

Quando il livello di compatibilità 110 o superiore, lo stile predefinito per le operazioni CAST e CONVERT sui tipi di dati time e datetime2 è sempre 121. Per altre informazioni, vedere Differenze tra i livelli di compatibilità inferiori e i livelli 100 e 110.

Per altre informazioni sugli stili di data e ora, vedere CAST e 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

I risultati restituiti sono simili ai seguenti:

TimeStyle0 TimeStyle121 Datetime2Style0 Datetime2Style121
3:15PM 15:15:35.8100000 Jun 7 2011 3:15PM 2011-06-07 15:15:35.8130000

E. Assegnazione di variabile - Operatore UNION di livello principale

Nell'impostazione del livello di compatibilità del database 90, l'assegnazione di variabili è consentita in un'istruzione contenente un operatore UNION di primo livello, ma restituisce risultati imprevisti. Nelle istruzioni seguenti, ad esempio, alla variabile locale @v è assegnato il valore della colonna BusinessEntityID dall'unione di due tabelle. Per definizione, quando l'istruzione SELECT restituisce più valori, alla variabile viene assegnato l'ultimo valore restituito. In questo caso, alla variabile viene assegnato correttamente l'ultimo valore, ma viene restituito anche il set di risultati dell'istruzione SELECT UNION.

ALTER DATABASE AdventureWorks2012
SET compatibility_level = 110;
GO
USE AdventureWorks2012;
GO
DECLARE @v int;
SELECT @v = BusinessEntityID FROM HumanResources.Employee
UNION ALL
SELECT @v = BusinessEntityID FROM HumanResources.EmployeeAddress;
SELECT @v;

Nell'impostazione del livello di compatibilità del database 100 e superiore, l'assegnazione di variabili non è consentita in un'istruzione contenente un operatore UNION di primo livello. In caso contrario, verrà restituito l'errore 10734.

Per risolvere questo errore, riscrivere la query come illustrato nell'esempio seguente.

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

Passaggi successivi

Per altre informazioni sui livelli di compatibilità del database e sui concetti correlati, vedere gli articoli seguenti: