Esporta (0) Stampa
Espandi tutto

Livello di compatibilità ALTER DATABASE (Transact-SQL)

Imposta aspetti specifici del funzionamento del database in modo che risultino compatibili con la versione specificata di SQL Server. La sintassi ALTER DATABASE seguente, che rappresenta una novità di SQL Server 2008, sostituisce la stored procedure sp_dbcmptlevel per l'impostazione del livello di compatibilità del database. Per altre opzioni relative ad ALTER DATABASE, vedere ALTER DATABASE (Transact-SQL).

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


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

database_name

Nome del database da modificare.

COMPATIBILITY_LEVEL { 80 | 90 | 100 }

Versione di SQL Server con cui il database deve risultare compatibile. Il valore deve essere uno dei seguenti:

80 = SQL Server 2000

90 = SQL Server 2005

100 = SQL Server 2008

Per tutte le installazioni di SQL Server 2008, il livello di compatibilità predefinito è 100. Per i database creati in SQL Server 2008 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 2008 da qualsiasi versione precedente di SQL Server, il database mantiene il livello di compatibilità esistente, se questo è almeno pari a 80. Se si aggiorna un database con un livello di compatibilità inferiore a 80, il livello di compatibilità viene impostato su 80. 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 2008, 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).

Opzioni SET

Le nuove funzionalità possono funzionare con livelli di compatibilità meno recenti ma è necessario regolare le opzioni SET. L'utilizzo del tipo di dati xml con il livello di compatibilità 80 richiede ad esempio l'impostazione delle opzioni ANSI SET appropriate. Quando inoltre il livello di compatibilità del database è impostato su 90 o su un valore superiore, l'impostazione di ANSI_WARNINGS su ON comporta l'impostazione implicita di ARITHABORT su ON. Se il livello di compatibilità del database è impostato su 80, l'opzione ARITHABORT deve essere impostata esplicitamente su ON. Per ulteriori informazioni, vedere Opzioni SET che hanno effetto sui risultati.

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à 80 e 90

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

Il livello di compatibilità 90 comporta le differenze di comportamento indicate di seguito.

Livello di compatibilità 80

Livello di compatibilità 90

Probabilità di impatto

Per gli hint di blocco nella clausola FROM, la parola chiave WITH è sempre facoltativa.

Con alcune eccezioni, gli hint di tabella sono supportati nella clausola FROM solo se vengono specificati con la parola chiave WITH. Per ulteriori informazioni, vedere FROM (Transact-SQL).

Alta

Gli operatori *= e =* per gli outer join sono supportati con un messaggio di avviso.

Questi operatori non sono supportati. È necessario utilizzare la parola chiave OUTER JOIN.

Alta

Quando si associano i riferimenti di colonna nell'elenco ORDER BY alle colonne definite nell'elenco SELECT, le eventuali ambiguità vengono ignorate e a volte vengono ignorati anche i prefissi di colonna. In questo caso è possibile che il set di risultati venga restituito in un ordine imprevisto.

Una clausola ORDER BY, ad esempio, composta da una singola colonna in due parti (<table_alias>.<column>) utilizzata come riferimento a una colonna in un elenco SELECT viene accettata, ma l'alias di tabella viene ignorato. Si consideri la query seguente.

SELECT c1 = -c1 FROM t_table AS x ORDER BY x.c1

Quando viene eseguita, il prefisso di colonna nella clausola ORDER BY viene ignorato. L'operazione di ordinamento non viene eseguita come previsto sulla colonna di origine specificata (x.c1) ma sulla colonna c1 derivata definita nella query. Il piano di esecuzione per questa query indica che vengono innanzitutto calcolati i valori per la colonna derivata e quindi i valori calcolati vengono ordinati.

Vengono generati errori in caso di ambiguità per le colonne. Gli eventuali prefissi di colonna specificati in ORDER BY non vengono ignorati durante l'associazione a una colonna definita nell'elenco SELECT.

Si consideri la query seguente.

SELECT c1 = -c1 FROM t_table AS x ORDER BY x.c1

Quando viene eseguita, il prefisso di colonna nella clausola ORDER BY non viene ignorato. L'operazione di ordinamento viene eseguita come previsto sulla colonna di origine specificata (x.c1). Il piano di esecuzione per questa query indica che l'operatore di ordinamento ordina le righe restituite da t_table e quindi vengono calcolati i valori per la colonna derivata c1 definita nell'elenco SELECT.

Media

In un'operazione INSERT SELECT da un'operazione UNION di tipi di dati diversi, per ogni ramo di UNION viene eseguito il cast diretto nel tipo della colonna di destinazione dell'operazione INSERT. Anche se l'unione potrebbe avere esito negativo a causa di conversioni di tipo non compatibili, se l'operazione venisse eseguita singolarmente, all'interno di INSERT SELECT l'operazione UNION viene completata perché il ramo per il tipo del risultato dell'operazione UNION non viene mai convertito.

Il tipo del risultato di un'operazione UNION viene derivato in modo indipendente da INSERT SELECT. Per ogni ramo di UNION viene eseguito il cast nel tipo del risultato di UNION e quindi viene eseguito il cast nel tipo della colonna di destinazione di INSERT. Se sono presenti tipi incompatibili nell'operazione UNION, il primo cast potrebbe causare un errore. Per utilizzare il livello di compatibilità 90, è necessario correggere tutte le unioni di tipi non compatibili utilizzate in operazioni INSERT SELECT.

Media

Le operazioni di inserimento e aggiornamento tramite una vista non sono supportate correttamente nelle viste che specificano la clausola WITH CHECK OPTION se la vista o una vista a cui viene fatto riferimento utilizza la clausola TOP.

Le operazioni di inserimento e aggiornamento tramite una vista non sono supportate nelle viste che specificano la clausola WITH CHECK OPTION se la vista o una vista a cui viene fatto riferimento utilizza la clausola TOP.

Media

L'applicazione dell'operatore UNION a una colonna a lunghezza variabile e a una colonna a lunghezza fissa genera una colonna a lunghezza fissa.

L'applicazione dell'operatore UNION a una colonna a lunghezza variabile e a una colonna a lunghezza fissa genera una colonna a lunghezza variabile.

Media

L'impostazione SET XACT_ABORT OFF viene ignorata in un trigger. L'opzione viene sempre impostata su ON.

SET XACT_ABORT può essere impostata su OFF in un trigger.

Media

La clausola FOR BROWSE è consentita (e ignorata) nelle viste.

La clausola FOR BROWSE non è consentita nelle viste.

Media

Gli errori di dominio non sono controllati da ANSI_WARNINGS. Le impostazioni ARITHABORT vengono rispettate, se l'opzione ANSI_WARNINGS è impostata su OFF e l'opzione ARITHABORT non viene modificata.

Anche gli errori di dominio vengono controllati da ANSI_WARNINGS e sono considerati errori con livello di gravità 16. Se l'opzione ANSI_WARNINGS o ARITHABORT è impostata su ON, viene generato un errore anziché restituire un valore NULL. Gli script degli utenti che dipendono dall'impostazione OFF per ARITHABORT potrebbero non funzionare più in seguito a questa modifica.

Media

Se una query pass-through eseguita su un'origine dei dati remota [OPENROWSET o OPENQUERY] restituisce colonne con nomi duplicati, i nomi di colonna duplicati vengono ignorati a meno che tali colonne non siano specificate in modo esplicito nella query.

Se una query pass-through eseguita su un'origine dei dati remota [OPENROWSET o OPENQUERY] restituisce una colonna con nomi di colonna duplicati, viene generato un errore.

Bassa

Le costanti stringa di caratteri e le costanti varbinary con dimensioni maggiori di 8000 vengono gestite come text, ntext o image.

Le costanti stringa di caratteri e le costanti varbinary con dimensioni maggiori di 8000 vengono gestite come il tipo varchar(max) (oppure rispettivamente nvarchar(max) e varbinary(max)). Ciò può causare la modifica del tipo di dati della tabella creata con SELECT … INTO se l'elenco SELECT contiene espressioni di questo tipo.

Bassa

I confronti tra tipi numerici (smallint, tinyint, int, bigint, numeric, decimal, smallmoney, money) vengono eseguiti tramite la conversione dell'elemento da confrontare con la precedenza inferiore nella gerarchia dei tipi nel tipo con precedenza maggiore.

I valori di tipo numerico vengono confrontati senza eseguire conversioni. Ciò consente di ottenere migliori prestazioni, ma è possibile che si generino differenze funzionali, in particolare nei casi in cui la conversione causa eccezioni di overflow.

Bassa

Le funzioni predefinite per i metadati che accettano argomenti stringa troncano l'input se più lungo di 4000 caratteri.

Le funzioni predefinite per i metadati generano un errore se il troncamento causa la perdita di caratteri diversi da spazi.

Bassa

Il gruppo di caratteri non consentiti in un identificatore senza virgolette è rimasto invariato.

Il parser Transact-SQL supporta lo standard Unicode 3.2, che modifica la classificazione dei caratteri per alcuni caratteri internazionali che ora non sono consentiti negli identificatori non delimitati.

Bassa

L'impostazione SET ANSI_WARNINGS ON non è prioritaria rispetto all'impostazione di SET ARITHABORT OFF nel caso di errori di dominio per valori a virgola mobile, ovvero argomenti negativi per la funzione log(). Se l'opzione ANSI_WARNINGS è impostata su ON ma ARITHABORT è OFF, gli errori di dominio per valori a virgola mobile non causano l'interruzione della query.

SET ANSI_WARNINGS ON sostituisce completamente l'impostazione ARITHABORT OFF. In questo caso, gli errori di dominio per valori a virgola mobile causano l'interruzione della query.

Bassa

Le costanti non integer sono consentite (e vengono ignorate) nella clausola ORDER BY.

Le costanti non integer non sono consente nella clausola ORDER BY.

Bassa

Sono consentite istruzioni SET vuote, ovvero senza assegnazioni di opzioni SET.

Non sono consentite clausole SET vuote.

Bassa

L'attributo IDENTITY non viene derivato correttamente per le colonne generate da una tabella derivata.

L'attributo IDENTITY viene derivato correttamente per le colonne generate da tabelle derivate.

Bassa

La proprietà per il supporto di valori Null degli operatori aritmetici applicati al tipo di dati a virgola mobile prevede sempre il supporto di valori Null.

La proprietà per il supporto di valori Null degli operatori aritmetici applicati al tipo di dati a virgola mobile viene modificata in modo da non consentire il supporto di valori Null, quando gli input non ammettono valori Null e l'opzione ANSI_WARNINGS è impostata su ON.

Bassa

Nell'istruzione INSERT .. SELECT con operatore UNION, i tipi generati dai singoli set dei risultati vengono tutti convertiti nel tipo della destinazione.

Nell'istruzione INSERT .. SELECT con operatore UNION, viene individuato il tipo dominante dei vari rami e i risultati vengono convertiti in tale tipo prima della conversione nel tipo della tabella di destinazione.

Bassa

Nell'istruzione SELECT .. FOR XML, i caratteri hex(27) (carattere ') e hex(22) (carattere " ) vengono sempre sostituiti con entità, anche se non richiesto.

FOR XML sostituisce con entità i caratteri hex(27) e hex(22) solo se necessario. Tali caratteri non vengono sostituiti con entità nelle situazioni seguenti:

  • Nel contenuto di attributi, il carattere hex(27) (carattere ') non viene sostituito con un'entità se i valori dell'attributo sono delimitati da " e il carattere hex(22) (carattere ") non viene sostituito con un'entità se i valori dell'attributo sono delimitati da '.

  • Nel contenuto degli elementi, i caratteri hex(27) e hex(22) non vengono mai sostituiti con entità.

Bassa

In FOR XML, il valore timestamp viene mappato a un valore integer.

In FOR XML, il valore timestamp viene mappato a un valore binary.

Per ulteriori informazioni, vedere Supporto del tipo di dati timestamp in FOR XML.

Alta (se si utilizza una colonna timestamp); bassa in caso contrario

In FOR XML e OPENXML, i character Unicode surrogati alti (high-range, 3 byte) nei nomi vengono rappresentati utilizzando 8 posizioni.

Ad esempio, utilizzando 8 posizioni FOR XML rappresenta il punto di codice Unicode U+10000 come:

<a_x00010000_ c1="1" />

In FOR XML e OPENXML, i caratteri Unicode surrogati alti (high-range, 3 byte) nei nomi vengono rappresentati utilizzando 6 posizioni.

Ad esempio, utilizzando 6 posizioni FOR XML rappresenta il punto di codice Unicode U+10000 come:

<a_x010000_ c1="1" />

Bassa

In FOR XML, i mapping di tabelle derivate in modalità AUTO vengono gestiti in modo trasparente.

Ad esempio:

USE AdventureWorks
CREATE TABLE Test(id int);
INSERT INTO Test VALUES(1);
INSERT INTO Test VALUES(2);
SELECT * FROM (SELECT a.id AS a, 
b.id AS b FROM Test a 
JOIN Test b ON a.id=b.id) 
Test FOR XML AUTO;

Se il livello di compatibilità per AdventureWorks è impostato su 80, l'esempio precedente restituisce:

<a a="1"><b b="1"/></a>

<a a="2"><b b="2"/></a>

In FOR XML, i mapping di tabelle derivate in modalità AUTO vengono gestiti in modo non trasparente.

Se il livello di compatibilità per AdventureWorks è impostato su 90, l'esempio precedente restituisce:

<Test a="1" b="1"/>

<Test a="2" b="2"/>

Alta (se alle viste è applicata la modalità FOR XML AUTO); bassa, in caso contrario

Le conversioni di stringhe nel tipo money supportano l'utilizzo di un carattere barra rovesciata (\) come simbolo di valuta solo per le lingue giapponese e coreano.

Il carattere barra rovesciata (\) è accettato per tutte le conversioni di stringhe nel tipo money in tutte le lingue. ISNUMERIC restituisce True se si utilizza \ come simbolo di valuta.

Per i database nelle versioni di SQL Server precedenti a SQL Server 2005, questo nuovo funzionamento compromette gli indici e le colonne calcolate che dipendono da un valore restituito ISNUMERIC che contiene \ e per cui la lingua non è giapponese o coreano.

Bassa

Il risultato di un operatore aritmetico ammette sempre i valori Null, anche se gli operandi non li ammettono e l'opzione ANSI_WARNINGS o ARITHABORT è impostata su ON.

Quando le opzioni ANSI_WARNINGS o ARITHABORT sono impostate su ON, il risultato di un operatore aritmetico a virgola mobile non ammette valori Null se entrambi gli operandi non ammettono valori Null.

Questa modifica nel supporto dei valori Null può causare errori se si utilizza bcp per un'esportazione bulk dei dati con formato binario da una tabella di SQL Server 2000 con una colonna calcolata che utilizza un operatore aritmetico a virgola mobile e si utilizza quindi bcp o BULK INSERT per l'importazione bulk di tali dati in una tabella di SQL Server 2005 con la stessa definizione.

Nota Nota
Se entrambe le opzioni sono impostate su OFF, Motore di database contrassegna il risultato per il supporto dei valori Null. Questo avviene anche in SQL Server 2000.

Bassa

Per le funzioni predefinite che accettano parametri di tipo nvarchar, se il valore specificato è varchar, il valore viene convertito in nvarchar(4000). In SQL Server 2000, se si passa un valore di dimensioni maggiori, questo viene troncato senza avvisare.

Per le funzioni predefinite che accettano parametri di tipo nvarchar, se il valore specificato è varchar, il valore viene ancora convertito in nvarchar(4000). Tuttavia, se si passa un valore di dimensioni maggiori, SQL Server 2008 genera un errore.

Per utilizzare il livello di compatibilità 90, è necessario correggere tutto il codice personalizzato che si basa sul funzionamento precedente di troncamento.

Bassa

L'unione di una stringa a lunghezza fissa (char, binary o nchar) con una stringa a lunghezza variabile (varchar, varbinary, nvarchar) restituisce un risultato a lunghezza fissa.

L'unione di una stringa di dimensioni variabili con una stringa di dimensioni fisse restituisce una stringa di dimensioni variabili.

Per utilizzare il livello di compatibilità 90, è necessario correggere tutti gli elementi (indici, query e colonne calcolate) che dipendono dal tipo risultate dall'unione di un tipo di dimensioni variabili con un tipo di dimensioni fisse.

Bassa

I nomi di oggetto contenenti il carattere 0xFFFF sono identificatori validi.

I nomi di oggetto contenenti il carattere 0xFFFF sono identificatori non validi e non è possibile accedervi.

Per utilizzare il livello di compatibilità 90, è necessario rinominare gli oggetti che contengono tale carattere.

Bassa

In SELECT ISNUMERIC('<string>'), le virgole incorporate all'interno di <string> sono significative.

La query SELECT ISNUMERIC('121212,12') seguente restituisce ad esempio 0. Questo indica che la stringa 121212,12 non è di tipo numerico.

In SELECT ISNUMERIC('<string>'), le virgole incorporate all'interno di <string> vengono ignorate.

La query SELECT ISNUMERIC('121212,12') seguente restituisce ad esempio 1. Questo indica che la stringa 121212,12 è di tipo numerico.

Bassa

Il segno di due punti (:) che segue una parola chiave riservata in un'istruzione Transact-SQL viene ignorato.

Il segno di due punti (:) che segue una parola chiave riservata in un'istruzione Transact-SQL determina l'esito negativo dell'istruzione.

Bassa

Una clausola GROUP BY in una sottoquery che fa riferimento a una colonna dalla query esterna ha esito positivo.

Una clausola GROUP BY in una sottoquery che fa riferimento a una colonna dalla query esterna restituisce un errore, in conformità allo standard SQL.

Bassa

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

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

Livello di compatibilità 90 o inferiore

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 runtime 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 runtime 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 runtime 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 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/@*'), ad esempio, restituisce tutti gli attributi che includono xsi:nil e xsi:type. Per escludere questi tipi nella query, sostituire @* con @*[namespace-uri(.) != "URI spazio dei nomi XSI" 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 è 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.

Per ulteriori informazioni sulle impostazioni delle opzioni necessarie, vedere Impostazione delle opzioni (dati di tipo XML).

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 EmployeeID 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 AdventureWorks
SET compatibility_level = 90;
GO
USE AdventureWorks;
GO
DECLARE @v int;
SELECT @v = EmployeeID FROM HumanResources.Employee
UNION ALL
SELECT @v = EmployeeID 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 = EmployeeID FROM 
    (SELECT EmployeeID FROM HumanResources.Employee
     UNION ALL
     SELECT EmployeeID 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

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

100

CUBE, MERGE, ROLLUP

90

EXTERNAL, PIVOT, UNPIVOT, REVERT, TABLESAMPLE

80

COLLATE, FUNCTION, OPENXML

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 100 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 100 corrispondenti a tale parole chiave non sono disponibili.

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

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

È richiesta l'autorizzazione ALTER per il database.

A. Modifica del livello di compatibilità

Nell'esempio seguente il livello di compatibilità del database AdventureWorks viene modificato e impostato su 90,SQL Server 2005.

ALTER DATABASE AdventureWorks
SET COMPATIBILITY_LEVEL = 90;
GO

B. Effetti del livello di compatibilità su ORDER BY (scenario 1)

Nell'esempio seguente viene illustrata la differenza per le associazioni ORDER BY con i livelli di compatibilità 80 e 100. Nell'esempio viene creata una tabella di esempio, SampleTable, nel database tempdb.

USE tempdb;
CREATE TABLE SampleTable(c1 int, c2 int);
GO

Con il livello di compatibilità 90, ovvero il livello predefinito, o uno superiore, l'istruzione SELECT... ORDER BY seguente genera un errore, in quanto l'alias di colonna nella clausola AS, c1, è ambiguo.

SELECT c1, c2 AS c1
FROM SampleTable
ORDER BY c1;
GO

Dopo aver reimpostato il livello di compatibilità del database su 80, la stessa istruzione SELECT... ORDER BY viene completata senza problemi.

ALTER DATABASE tempdb
SET COMPATIBILITY_LEVEL = 80;
GO
SELECT c1, c2 AS c1
FROM SampleTable
ORDER BY c1;
GO

L'istruzione SELECT... ORDER BY seguente viene eseguita correttamente in entrambi i livelli di compatibilità, in quanto nella clausola AS viene specificato un alias non ambiguo.

ALTER DATABASE tempdb
SET COMPATIBILITY_LEVEL = 100;
GO
SELECT c1, c2 AS c3
FROM SampleTable
ORDER BY c1;
GO

ALTER DATABASE tempdb
SET COMPATIBILITY_LEVEL = 80;
GO
SELECT c1, c2 AS c3
FROM SampleTable
ORDER BY c1;
GO

B. Effetti del livello di compatibilità su ORDER BY (scenario 2)

Con il livello di compatibilità 90, ovvero il livello predefinito, o uno superiore, l'istruzione SELECT...ORDER BY seguente genera un errore, in quanto l'alias di colonna specificato nella clausola ORDER BY contiene un prefisso di tabella.

SELECT c1 AS x
FROM SampleTable
ORDER BY SampleTable.x;
GO

Dopo aver reimpostato il livello di compatibilità del database su 80, la stessa istruzione SELECT...ORDER BY ha esito positivo.

ALTER DATABASE tempdb
SET COMPATIBILITY_LEVEL = 80;
GO
SELECT c1 AS x
FROM SampleTable
ORDER BY SampleTable.x;
GO

L'istruzione SELECT...ORDER BY seguente viene eseguita correttamente in entrambi i livelli di compatibilità, in quanto il prefisso di tabella viene rimosso dall'alias di colonna specificato nella clausola ORDER BY.

ALTER DATABASE tempdb
SET COMPATIBILITY_LEVEL = 100;
GO
SELECT c1 AS x
FROM SampleTable
ORDER BY x;
GO
ALTER DATABASE tempdb
SET COMPATIBILITY_LEVEL = 80;
GO
SELECT c1 AS x
FROM SampleTable
ORDER BY x;
GO

Aggiornamento del contenuto

Correzione del comportamento dell'istruzione XACT_ABORT se specificata in un trigger. L'impostazione di XACT_ABORT su OFF in un trigger viene ignorata con il livello di compatibilità 80 ed è consentita con il livello di compatibilità 90 o superiore. Nella documentazione precedente queste informazioni risultano invertite.

Il documento è risultato utile?
(1500 caratteri rimanenti)
Grazie per i commenti inviati.

Aggiunte alla community

AGGIUNGI
Microsoft sta conducendo un sondaggio in linea per comprendere l'opinione degli utenti in merito al sito Web di MSDN. Se si sceglie di partecipare, quando si lascia il sito Web di MSDN verrà visualizzato il sondaggio in linea.

Si desidera partecipare?
Mostra:
© 2014 Microsoft