Condividi tramite

Livello di compatibilità ALTER DATABASE (Transact-SQL)

  • Articolo

Imposta aspetti specifici del comportamento del database in modo che risultino compatibili con la versione specificata di SQL Server. Per altre opzioni relative ad ALTER DATABASE, vedere ALTER DATABASE (Transact-SQL).

Icona di collegamento a un argomento Convenzioni della sintassi Transact-SQL

Sintassi

ALTER DATABASE database_name 
SET COMPATIBILITY_LEVEL = { 90 | 100 | 110 }

Argomenti

  • database_name
    Nome del database da modificare.

  • COMPATIBILITY_LEVEL { 90 | 100 | 110 }
    Versione di SQL Server con cui il database deve risultare compatibile. Il valore deve essere uno dei seguenti:

    90 = SQL Server 2005

    100 = SQL Server 2008 e SQL Server 2008 R2

    110 = SQL Server 2012

Osservazioni

Per tutte le installazioni di SQL Server 2012, il livello di compatibilità predefinito è 110. Per i database creati in SQL Server 2012 viene impostato questo livello, a meno che per il database model non sia impostato un livello di compatibilità inferiore. Quando si aggiorna un database a SQL Server 2012 da qualsiasi versione precedente di SQL Server, il database mantiene il livello di compatibilità esistente, se questo è almeno pari a 90. Se si aggiorna un database con un livello di compatibilità inferiore a 90, il livello di compatibilità viene impostato su 90. Questo comportamento si applica sia ai database di sistema che ai database utente. Utilizzare ALTER DATABASE per modificare il livello di compatibilità del database. Per visualizzare il livello di compatibilità corrente di un database, eseguire una query sulla colonna compatibility_level nella vista del catalogo sys.databases.

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

Il livello di compatibilità influisce solo sul comportamento del database specificato e non dell'intero server. Il livello di compatibilità garantisce solo una compatibilità parziale con le versioni precedenti di SQL Server. Utilizzare il livello di compatibilità come strumento di migrazione provvisoria per risolvere i problemi correlati alle differenze tra le versioni delle funzioni controllate dall'impostazione del livello di compatibilità pertinente. In presenza di applicazioni esistenti di SQL Server interessate da differenze funzionali introdotte in SQL Server 2012, convertire l'applicazione per ottenere il funzionamento corretto, Utilizzare quindi ALTER DATABASE per modificare il livello di compatibilità impostandolo su 100. La nuova impostazione del livello di compatibilità per un database diventa effettiva la volta successiva che il database diventa corrente, sia come database predefinito all'accesso o perché specificato in un'istruzione USE.

Procedure consigliate

Se si modifica il livello di compatibilità mentre gli utenti sono connessi al database, è possibile che vengano restituiti set di risultati non corretti per le query attive. Se ad esempio si modifica il livello di compatibilità durante la compilazione di un piano di query, è possibile che il piano compilato sia basato sui livelli di compatibilità sia vecchi che nuovi, con conseguente restituzione di un piano non corretto e di risultati potenzialmente non accurati. Il problema potrebbe essere inoltre aggravato dal fatto che il piano venga inserito nella cache dei piani e riutilizzato per query successive. Per evitare risultati di query non accurati, è consigliabile utilizzare la procedura seguente per modificare il livello di compatibilità di un database:

  1. Impostare il database in modalità di accesso utente singolo utilizzando ALTER DATABASE SET SINGLE_USER.

  2. Modificare il livello di compatibilità del database.

  3. Impostare il database in modalità di accesso multiutente utilizzando ALTER DATABASE SET MULTI_USER.

  4. Per ulteriori informazioni sull'impostazione della modalità di accesso di un database, vedere ALTER DATABASE (Transact-SQL).

Livelli di compatibilità e stored procedure

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

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 utilizzata 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.

I predicati full-text non sono consentiti nella clausola OUTPUT.

Bassa

Le funzioni 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 funzioni CREATE FULLTEXT STOPLIST, ALTER FULLTEXT STOPLIST e DROP FULLTEXT STOPLIST sono supportate.

Bassa

MERGE non viene applicata come parola chiave riservata.

MERGE è una parola chiave completamente riservata. L'istruzione MERGE è supportata con i livelli di compatibilità 100 e 90.

Bassa

Se si utilizza 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, utilizzare l'argomento <dml_table_source> dell'istruzione INSERT.

Bassa

A meno che non sia specificato NOINDEX, DBCC CHECKDB o DBCC CHECKTABLE esegue controlli di consistenza sia fisica che 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 che 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.

Bassa

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 utilizzata con un'istruzione DML (Data Manipulation Language) e si verifica un errore di run-time durante l'esecuzione di istruzioni, il comportamento dipende dall'impostazione di SET XACT_ABORT. Se SET XACT_ABORT è 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 è ON, tutti gli errori di run-time generati dall'istruzione DML tramite la clausola OUTPUT termineranno il batch e verrà eseguito il rollback della transazione.

Bassa

CUBE e ROLLUP non vengono applicate come parole chiave riservate.

CUBE e ROLLUP sono parole chiave riservate all'interno della clausola GROUP BY.

Bassa

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 ulteriori informazioni, vedere Componenti jolly e convalida del contenuto.

Bassa

Non è possibile eseguire query sugli attributi speciali xsi:nil e xsi:type, né modificarli tramite istruzioni Data Manipulation Language.

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".

Bassa

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.

Bassa

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

Bassa

Le opzioni SET necessarie per un metodo xQuery non vengono convalidate quando il metodo è contenuto in una vista o in una funzione inline con valori di tabella.

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.

Bassa

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.

Bassa

Le proprietà di colonna ROWGUIDCOL e IDENTITY possono essere erroneamente denominate come un 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 un vincolo. In caso contrario, verrà restituito l'errore 156.

Bassa

L'aggiornamento di colonne tramite un'assegnazione bidirezionale, ad esempio UPDATE T1 SET @v = column_name = <expression>, può produrre risultati imprevisti, in quanto è possibile che durante l'esecuzione dell'istruzione in altre clausole quali WHERE e ON venga utilizzato 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.

Bassa

L'assegnazione di variabile è consentita in un'istruzione contenente un operatore UNION di livello principale, 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 = 90;
GO
USE AdventureWorks2012;
GO
DECLARE @v int;
SELECT @v = BusinessEntityID FROM HumanResources.Employee
UNION ALL
SELECT @v = BusinessEntityID FROM HumanResources.EmployeeAddress;
SELECT @v;

L'assegnazione di variabile non è consentita in un'istruzione contenente un operatore UNION di livello principale. 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;

Bassa

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'utilizzo del formato AMG.

La funzione ODBC {fn CONVERT()} utilizza 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.

Bassa

La funzione ODBC {fn CURDATE()} restituisce solo la data in formato 'AAAA-MM-GG'.

La funzione ODBC {fn CURDATE()} restituisce sia la data che l'ora, ad esempio 'AAAA-MM-GG hh:mm:ss'.

Bassa

Le funzioni intrinseche datetime, ad esempio DATEPART, non richiedono che i valori di input di tipo stringa siano valori letterali datetime validi. La funzione SELECT DATEPART (year, '2007/05-30'), ad esempio, viene compilata 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.

Bassa

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

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

Livello di compatibilità 100 o inferiore

Livello di compatibilità 110

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 ulteriori informazioni, vedere Novità dell'integrazione con CLR.

Gli oggetti di database CLR vengono eseguiti con la versione 4 di CLR.

Le funzioni XQuery string-length e substring considerano ciascun surrogato come due caratteri.

Le funzioni XQuery string-length e substring considerano ciascun surrogato come un carattere.

L'operatore PIVOT è consentito in una query ricorsiva dell'espressione di tabella comune. La query tuttavia restituisce risultati non corretti quando sono presenti più righe per raggruppamento.

L'operatore PIVOT non è consentito in una query ricorsiva dell'espressione di tabella comune. Viene restituito un errore.

L'algoritmo RC4 è supportato solo per motivi di compatibilità con le versioni precedenti. È possibile crittografare il nuovo materiale utilizzando RC4 o RC4_128 solo quando il livello di compatibilità del database è 90 o 100 (non consigliato). In SQL Server 2012 il materiale crittografato utilizzando RC4 o RC4_128 può essere decrittografato in qualsiasi livello di compatibilità.

Il nuovo materiale non può essere crittografato utilizzando RC4 o RC4_128. Utilizzare un algoritmo più recente, ad esempio uno degli algoritmi AES. In SQL Server 2012 il materiale crittografato utilizzando 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 utilizzato in un'espressione di colonna calcolata. Per le colonne calcolate, lo stile predefinito è 0. Questo comportamento influisce sulle colonne calcolate quando vengono create o utilizzate nelle query con parametrizzazione automatica o nelle definizioni dei vincoli.

Nell'esempio seguente viene illustrata la differenza tra gli stili 0 e 121. Non viene illustrato il comportamento descritto sopra. Per ulteriori informazioni sugli stili della data e dell'ora, vedere CAST e CONVERT (Transact-SQL).

CREATE TABLE t1 (c1 time(7), c2 datetime2); 
INSERT t1 (c1,c2) VALUES (GETDATE(), GETDATE());
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;
-- Returns values such as the following.
TimeStyle0       TimeStyle121     Datetime2Style0      Datetime2Style121
---------------- ---------------- -------------------- --------------------------
3:15PM           15:15:35.8100000 Jun  7 2011  3:15PM  2011-06-07 15:15:35.8130000

Con il livello di compatibilità 110, lo stile predefinito per le operazioni CAST e CONVERT sui tipi di dati time e datetime2 è sempre 121. Se la query si basa sul comportamento obsoleto, utilizzare 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 utilizza SELECT INTO per creare una tabella da un'origine che contiene un'espressione di colonna calcolata descritta in precedenza, vengono archiviati i dati (con stile 0), non la definizione della colonna calcolata. Sarà necessario aggiornare manualmente questi dati in base allo stile 121.

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 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 effettuato l'aggiornamento al livello di compatibilità 110, potrebbe essere necessario ricompilare gli indici, gli heap o i vincoli CHECK in cui viene utilizzata la funzione SOUNDEX. Per ulteriori informazioni, vedere SOUNDEX (Transact-SQL)

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

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 anche per i livelli 100 e 110.

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

Per ulteriori informazioni, vedere Parole chiave riservate (Transact-SQL).

Autorizzazioni

È richiesta l'autorizzazione ALTER per il database.

Esempi

A.Modifica del livello di compatibilità

Nell'esempio seguente il livello di compatibilità del database AdventureWorks2012 viene modificato e impostato su 110, SQL Server 2012.

ALTER DATABASE AdventureWorks2012
SET COMPATIBILITY_LEVEL = 110;
GO

Vedere anche

Riferimento

ALTER DATABASE (Transact-SQL)

Parole chiave riservate (Transact-SQL)

CREATE DATABASE (Transact-SQL)

DATABASEPROPERTYEX (Transact-SQL)

sys.databases (Transact-SQL)

sys.database_files (Transact-SQL)