Partager via

  • Article

Niveau de compatibilité ALTER DATABASE (Transact-SQL)

Définit certains comportements de base de données pour qu'ils soient compatibles avec la version de SQL Server spécifiée. La syntaxe ALTER DATABASE suivante remplace la procédure sp_dbcmptlevel pour définir le niveau de compatibilité des bases de données. Pour obtenir des informations sur d'autres options ALTER DATABASE, consultez ALTER DATABASE (Transact-SQL).

Icône Lien de rubriqueConventions de syntaxe Transact-SQL

Syntaxe

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

Arguments

  • database_name
    Nom de la base de données à modifier.

  • COMPATIBILITY_LEVEL { 80 | 90 | 100 }
    Version de SQL Server avec laquelle la base de données doit être compatible. La valeur doit être l'une des suivantes :

    80 = SQL Server 2000 

    90 = SQL Server 2005 

    100 = SQL Server 2008 

Notes

Pour toutes les installations de SQL Server 2008, le niveau de compatibilité par défaut est 100. Il s'agit du niveau défini pour les bases de données créées dans SQL Server 2008, à moins que le niveau de compatibilité de la base de données model soit inférieur. Lorsqu'une base de données est mise à niveau vers SQL Server 2008 à partir d'une version antérieure quelconque de SQL Server, la base de données conserve son niveau de compatibilité existant, s'il est au moins de 80. Mettre à niveau une base de données avec un niveau de compatibilité inférieur à 80 affecte à la base de données le niveau de compatibilité 80. Cela s'applique aussi bien aux bases de données système qu'aux bases de données utilisateur. Utilisez ALTER DATABASE pour modifier le niveau de compatibilité de la base de données. Pour afficher le niveau de compatibilité actuel d'une base de données, exécutez une requête sur la colonne compatibility_level de l'affichage catalogue sys.databases.

Utilisation du niveau de compatibilité pour la compatibilité descendante

Le niveau de compatibilité affecte uniquement les comportements de la base de données spécifiée et non ceux du serveur tout entier. Le niveau de compatibilité fournit uniquement une compatibilité descendante partielle avec les versions antérieures de SQL Server. Utilisez le niveau de compatibilité en tant qu'aide à la migration intérimaire pour contourner les problèmes liés aux différences de version dans les comportements qui sont contrôlés par le paramètre de niveau de compatibilité correspondant. Si des applications SQL Server existantes sont affectées par des différences de comportement dans SQL Server 2008, convertissez l'application afin qu'elle fonctionne correctement. Utilisez ensuite ALTER DATABASE pour changer le niveau de compatibilité en spécifiant 100. Le nouveau paramètre de compatibilité d'une base de données devient effectif lorsque la base de données devient ensuite active (soit comme base de données par défaut lors de la connexion, soit lorsqu'elle est spécifiée dans une instruction USE).

Meilleures pratiques

La modification du niveau de compatibilité alors que des utilisateurs sont connectés à la base de données peut générer des jeux de résultats incorrects pour les requêtes actives. Par exemple, si le niveau de compatibilité change alors qu'un plan de requête est en cours de compilation, le plan compilé peut être basé à la fois sur l'ancien niveau de compatibilité et sur le nouveau, ce qui aboutit à un plan incorrect et à des résultats éventuellement erronés. En outre, le problème peut être aggravé si le plan est placé dans la mémoire cache du plan et réutilisé pour des requêtes ultérieures. Pour éviter que les requêtes ne donnent des résultats inexacts, nous vous recommandons d'utiliser la procédure suivante pour modifier le niveau de compatibilité d'une base de données :

  1. Placez la base de données en mode d'accès mono-utilisateur en utilisant ALTER DATABASE SET SINGLE_USER.

  2. Modifiez le niveau de compatibilité de la base de données.

  3. Placez la base de données en mode d'accès multi-utilisateur en utilisant ALTER DATABASE SET MULTI_USER.

  4. Pour plus d'informations sur la définition du mode d'accès d'une base de données, consultez ALTER DATABASE (Transact-SQL).

Options SET

Les nouvelles fonctionnalités peuvent éventuellement s'accommoder de niveaux de compatibilité plus anciens, mais les options SET nécessitent quelques ajustements. L'utilisation, par exemple, du type de données xml sous le niveau de compatibilité 80 requiert des options ANSI SET appropriées. En outre, lorsque le niveau de compatibilité de base de données est d'au moins 90, l'affectation de la valeur ON à ANSI_WARNINGS affecte de manière implicite la valeur ON à ARITHABORT. Si le niveau de compatibilité de la base de données est 80, l'option ARITHABORT doit explicitement être activée (ON). Pour plus d'informations, consultez Options SET affectant les résultats.

Niveaux de compatibilité et procédures stockées

Lors de l'exécution d'une procédure stockée, elle utilise le niveau de compatibilité en cours de la base de données dans laquelle elle est définie. Lors de la modification du paramètre de compatibilité d'une base de données, l'ensemble de ses procédures stockées sont automatiquement recompilées en conséquence.

Différences entre le niveau de compatibilité 80 et le niveau 90

Cette section décrit les nouveaux comportements introduits avec le niveau de compatibilité 90.

Avec le niveau de compatibilité 90, les changements de comportement suivants sont observés.

Paramètre de niveau de compatibilité égal à 80

Paramètre de niveau de compatibilité égal à 90

Possibilité d'impact

Pour les indicateurs de verrouillage dans la clause FROM, le mot clé WITH est toujours facultatif.

À quelques exceptions près, les indicateurs de table sont pris en charge dans la clause FROM uniquement lorsque les indicateurs sont spécifiés à l'aide du mot clé WITH. Pour plus d'informations, consultez FROM (Transact-SQL).

Élevée

Les opérateurs *= et =* pour la jointure externe sont pris en charge avec un message d'avertissement.

Ces opérateurs ne sont pas pris en charge ; le mot clé OUTER JOIN doit être utilisé.

Élevée

Lors de la liaison des références de colonnes de la liste ORDER BY avec les colonnes définies dans la liste SELECT, les ambiguïtés de colonnes sont ignorées et les préfixes de colonnes parfois ignorés. Cette situation peut retourner l'ensemble de résultats dans un ordre inattendu.

Ainsi, une clause ORDER BY composée d'une colonne unique en deux parties (<table_alias>.<column>), elle-même utilisée comme référence à une colonne dans une liste SELECT, est acceptée, mais l'alias de table est ignoré. Considérez la requête ci-dessous.

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

Lorsqu'elle est exécutée, le préfixe de colonne est ignoré dans ORDER BY. L'opération de tri ne se produit pas sur la colonne source spécifiée (x.c1) comme prévu, mais sur la colonne c1 dérivée définie dans la requête. Le plan d'exécution de cette requête indique que les valeurs de la colonne dérivée sont calculées puis que les valeurs calculées sont triées.

Des erreurs sont signalées concernant les ambiguïtés de colonne. Les préfixes de colonne spécifiés, le cas échéant, dans ORDER BY, ne sont pas ignorés lors de la liaison à la colonne définie dans la liste SELECT.

Considérez la requête suivante.

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

Lorsqu'elle est exécutée, le préfixe de colonne dans la clause ORDER BY est ignoré. L'opération de tri se produit sur la colonne source spécifiée (x.c1), comme prévu. Le plan d'exécution de cette requête indique que l'opérateur de tri classe les lignes renvoyées à partir de t_table, puis que les valeurs de la colonne dérivée c1 définie dans la liste SELECT sont calculées. Dans ce cas, l'ordre des résultats peut être différent des résultats retournés dans SQL Server 2000. Pour parvenir au même ordre de résultats que dans SQL Server 2000, supprimez le préfixe de colonne dans la clause ORDER BY.

Moyenne

Dans une instruction INSERT SELECT à partir d'une UNION de différents types de données, chaque branche UNION est directement convertie selon le type de colonne cible de l'instruction INSERT. Même si l'union utilisée par elle-même risque d'échouer en raison de conversions de types incompatibles, l'instruction INSERT SELECT permet à l'UNION de réussir car la branche vers le type de résultat de l'UNION n'est jamais convertie.

Le type de résultat de l'UNION dérive indépendamment de l'instruction INSERT SELECT. Chaque branche de l'UNION est convertie selon le type de résultat de l'UNION, puis convertie d'après le type de la colonne cible de l'instruction INSERT. S'il existe des types incompatibles dans l'UNION, la première conversion risque d'entraîner une erreur. Pour une exécution au niveau de compatibilité 90, vous devez résoudre toutes les unions de type incompatible utilisées dans l'instruction INSERT SELECT.

Moyenne

Les opérations d'insertion et de mise à jour par le biais d'une vue ne sont pas gérées correctement pour les vues qui spécifient la clause WITH CHECK OPTION lorsque la vue ou une vue référencée utilise la clause TOP.

Les opérations d'insertion et de mise à jour par le biais d'une vue ne sont pas gérées pour les vues qui utilisent WITH CHECK OPTION lorsque la vue ou une vue référencée utilise la clause TOP.

Moyenne

L'UNION d'une colonne de longueur variable avec une colonne de longueur fixe produit une colonne de longueur fixe.

L'expression CASE retourne un type de longueur fixe (char) si elle inclut des valeurs char et varchar.

L'UNION d'une colonne de longueur variable avec une colonne de longueur fixe produit une colonne de longueur variable.

L'expression CASE retourne un type de longueur variable (varchar) si elle inclut des valeurs char et varchar.

Moyenne

SET XACT_ABORT OFF est autorisé au sein d'un déclencheur.

SET XACT_ABORT OFF n'est pas autorisé au sein d'un déclencheur.

Moyenne

La clause FOR BROWSE est autorisée (et ignorée) dans les vues.

La clause FOR BROWSE n'est pas autorisée dans les vues.

Moyenne

Les erreurs de domaine ne sont pas contrôlées par ANSI_WARNINGS. Les paramètres ARITHABORT sont respectés, si ANSI_WARNINGS possèdent la valeur OFF et que ARITHABORT ne fait l'objet d'aucune modification.

Les erreurs de domaine sont aussi contrôlées par ANSI_WARNINGS et constituent des erreurs de gravité 16. Si ANSI_WARNINGS ou ARITHABORT ont la valeur ON, une erreur est émise au lieu de retourner une valeur NULL. Cette modification risque d'empêcher le fonctionnement des scripts utilisateur qui dépendent du fait que ARITHABORT ait la valeur OFF ou non.

Moyenne

Si une requête de relais et une source de données distante [OpenRowset ou OpenQuery] produisent des colonnes avec des doublons de nom, les noms de colonne dupliqués sont ignorés, sauf si les colonnes sont explicitement nommées dans la requête.

Si une requête de relais et une source de données distante [OpenRowset ou OpenQuery] produisent une colonne avec des doublons de nom de colonne, une erreur est générée.

Faible

Les constantes de type chaîne de caractères et les constantes de type varbinary d'une taille supérieure à 8 000 sont traitées comme des données de type text, ntext ou image.

Les constantes de type chaîne de caractères et les constantes de type varbinary d'une taille supérieure à 8 000 sont traitées comme des données de type varchar(max) (ou nvarchar(max) et varbinary(max), respectivement). Cela peut modifier le type de données de la table créée à l'aide de SELECT … INTO si la liste SELECT contient de telles expressions.

Basse

Les comparaisons entre types numériques (smallint, tinyint, int, bigint, numeric, decimal, smallmoney, money) s'effectuent en convertissant les éléments de comparaison avec une précédence inférieure dans la hiérarchie de type par rapport au type dont la précédence est plus élevée.

Les valeurs de type numérique sont comparées sans conversion. Ce mode fournit de meilleures performances. Cependant, il peut entraîner certaines modifications dans le comportement, notamment dans des cas où la conversion a entraîné des exceptions de dépassement.

Faible

Les fonctions de métadonnées intégrées nécessitant des arguments de chaîne tronquent leur entrée si l'entrée excède 4 000 caractères.

Des fonctions de métadonnées intégrées signalent une erreur si la troncation entraîne une perte de caractères sans espace.

Faible

L'ensemble de caractères désactivés dans un identificateur sans guillemets demeurent inchangés.

L'analyseur Transact-SQL prend en charge la norme Unicode 3.2, qui modifie la classification des caractères pour certains caractères internationaux qui ne sont pas autorisés dans des identificateurs non délimités.

Faible

SET ANSI_WARNINGS ON ne remplace pas le paramètre de SET ARITHABORT OFF dans le cas d'erreurs de domaine de virgule flottante [arguments négatifs pour la fonction log()]. Si ANSI_WARNINGS a la valeur ON mais que ARITHABORT a la valeur OFF, les erreurs de domaine de virgule flottante n'entraînent pas l'arrêt de la requête.

SET ANSI_WARNINGS ON remplace entièrement le paramètre ARITHABORT OFF. Dans ce cas, les erreurs de domaine de virgule flottante entraînent l'arrêt de la requête.

Faible

Les constantes de type non entier sont autorisées (et ignorées) dans la clause ORDER BY.

Les constantes de type non entier ne sont pas autorisées dans la clause ORDER BY.

Faible

Une instruction SET vide (sans option SET) est autorisée.

Une clause SET vide n'est pas autorisée.

Faible

L'attribut IDENTITY n'est pas dérivé correctement pour les colonnes produites par une table dérivée.

L'attribut IDENTITY est dérivé correctement pour les colonnes produites par des tables dérivées.

Faible

La propriété de possibilité de valeur NULL d'opérateurs arithmétiques pour un type de données à virgule flottante permet toujours d'accepter les valeurs NULL.

La propriété de possibilité de valeur NULL d'opérateurs arithmétiques pour un type de données à virgule flottante est modifiée pour ne pas accepter les valeurs NULL, dans le cas où les entrées ne peuvent pas accepter les valeurs NULL et où ANSI_WARNINGS ou ARITHABORT a la valeur ON.

Faible

Dans l'instruction INSERT SELECT avec UNION, les types produits par les jeux de résultats individuels sont tous convertis vers le type de résultat de destination.

Dans l'instruction INSERT .. SELECT avec UNION, le type dominant des différentes branches est déterminé et les résultats convertis vers ce type avant d'être convertis vers le type de la table de destination.

Faible

Dans l'instruction SELECT .. FOR XML, hex(27) (caractère ') et hex(22) (caractère ") sont toujours décomposés en entités, même lorsque cela n'est pas nécessaire.

FOR XML décompose hex(27) et hex(22) en entités uniquement lorsque cela est requis. Ils ne sont pas décomposés en entités dans les situations suivantes :

  • Dans le contenu d'attribut, hex(27) (caractère ') n'est pas décomposé en entités si les valeurs d'attribut sont délimitées avec ", tandis que hex(22) (caractère ") n'est pas décomposé en entités si les valeurs d'attribut sont délimitées par '.

  • Dans le contenu d'élément, hex(27) et hex(22) ne sont jamais décomposés en entités.

Faible

Dans FOR XML, la valeur du cachet de date est mappée à un entier.

Dans FOR XML, la valeur d'horodateur est mappée à une valeur binaire.

Pour plus d'informations, consultez Prise en charge de FOR XML pour le type de données timestamp.

Élevée (si une colonne timestamp est utilisée) ; sinon, faible.

Dans FOR XML et OPENXML, les caractères Unicode à plage élevée (3 octets) dans les noms sont représentés à l'aide de 8 positions.

Avec l'utilisation, par exemple, de 8 positions, FOR XML représente le point de code Unicode U+10000 sous la forme :

<a_x00010000_ c1="1" />

Dans FOR XML et OPENXML, les caractères Unicode à plage élevée (3 octets) dans les noms sont représentés à l'aide de 6 positions.

Avec l'utilisation, par exemple, de 6 positions, FOR XML représente le point de code Unicode U+10000 sous la forme :

<a_x010000_ c1="1" />

Faible

Dans FOR XML, des mappages de table dérivée en mode AUTO sont traités de manière transparente.

Par exemple :

USE AdventureWorks2008R2;
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;

Lorsque le niveau de compatibilité d'AdventureWorks2008R2 est défini à 80, l'exemple ci-dessus produit :

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

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

Dans FOR XML, des mappages de table dérivée en mode AUTO sont traités de manière opaque.

Lorsque le niveau de compatibilité d'AdventureWorks2008R2 est défini à 90, l'exemple précédent produit :

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

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

Élevée (si le mode FOR XML AUTO est appliqué sur des vues) ; sinon, faible

Les conversions de données de type chaîne en données money prennent en charge l'utilisation d'une barre oblique inverse (\) comme symbole de devise uniquement dans les langues japonaise et coréenne.

La barre oblique inverse (\) est acceptée dans toutes les conversions de données de type chaîne en données money, dans toutes les langues. ISNUMERIC retourne true lorsque le caractère \ est utilisé comme symbole de devise.

Pour les bases de données des versions de SQL Server antérieures à SQL Server 2005, ce nouveau comportement empêche le fonctionnement des index et des colonnes calculées qui dépendent d'une valeur de retour ISNUMERIC qui contient le caractère \ et dont la langue n'est ni le japonais ni le coréen.

Faible

Le résultat d'un opérateur arithmétique accepte toujours les valeurs NULL, même si les opérandes n'acceptent pas les valeurs NULL et que ANSI_WARNINGS ou ARITHABORT a la valeur ON.

Lorsque ANSI_WARNINGS ou ARITHABORT ont la valeur ON, le résultat d'un opérateur arithmétique à virgule flottante n'accepte pas les valeurs NULL, si les deux opérandes n'acceptent pas les valeurs NULL.

Cette modification de la possibilité de valeur NULL peut entraîner un échec lorsque bcp sert à l'exportation en bloc de données utilisant le format binaire à partir d'une table SQL Server 2000, avec une colonne calculée qui utilise un opérateur arithmétique à virgule flottante, puis lorsque bcp ou BULK INSERT est utilisé pour l'importation en bloc de données dans une table SQL Server 2005 avec la même définition.

RemarqueRemarque
Lorsque les deux options ont la valeur OFF, le Moteur de base de données marque le résultat comme acceptant les valeurs NULL. Ce comportement est identique dans SQL Server 2000.

Faible

Pour des fonctions intégrées utilisant le paramètre nvarchar, si la valeur fournie est de type varchar, cette valeur est convertie en type nvarchar(4000). Dans SQL Server 2000, si une valeur plus importante est transmise, elle est tronquée en mode silencieux.

Pour des fonctions intégrées utilisant le paramètre nvarchar, si la valeur fournie est de type varchar, cette valeur est toujours convertie en type nvarchar(4000). Cependant, si une valeur plus importante est transmise, SQL Server 2008 génère une erreur.

Pour une exécution au niveau de compatibilité 90, vous devez corriger tout code personnalisé qui dépend du comportement de la troncation.

Faible

L'union d'une chaîne de longueur fixe (char, binary ou nchar) avec une chaîne de longueur variable (varchar, varbinary, nvarchar) retourne un résultat de longueur fixe.

L'union d'une chaîne de longueur variable avec une chaîne de longueur fixe retourne une chaîne de longueur variable.

Pour une exécution avec un niveau de compatibilité 90, vous devez résoudre toutes les insertions (index, requêtes et colonnes calculées) dépendant du type résultant d'une union entre un type de taille variable et un type de taille fixe.

Faible

Les noms d'objet contenant le caractère 0xFFFF constituent des identificateurs valides.

Les noms d'objet contenant les caractères 0xFFFF sont des identificateurs non valides et sont inaccessibles.

Pour une exécution avec le niveau de compatibilité 90, vous devez renommer des objets contenant ce caractère.

Faible

Dans SELECT ISNUMERIC('<string>'), les virgules présentes dans <string> ont toutes leur importance.

Par exemple, la requête SELECT ISNUMERIC('121212,12') ci-dessous retourne 0. Cela indique que la chaîne 121212,12 n'est pas numérique.

Dans SELECT ISNUMERIC('<string>'), les virgules présentes dans <string> sont ignorées.

Par exemple, la requête SELECT ISNUMERIC('121212,12') ci-dessous retourne 1. Cela indique que la chaîne 121212,12 est numérique.

Faible

Un caractère deux-points (:) suivant un mot clé réservé dans une instruction Transact-SQL est ignoré.

Un caractère deux-points (:) suivant un mot clé réservé dans une instruction Transact-SQL provoque l'échec de l'instruction.

Faible

Dans une sous-requête, une clause GROUP BY qui référence une colonne de la requête externe réussit.

Dans une sous-requête, une clause GROUP BY qui référence une colonne de la requête externe retourne une erreur conformément à la norme SQL.

Faible

Différences entre les niveaux de compatibilité inférieurs et le niveau 100

Cette section décrit les nouveaux comportements introduits avec le niveau de compatibilité 100.

Paramètre de niveau de compatibilité inférieur ou égal à 90

Paramètre de niveau de compatibilité égal à 100

Possibilité d'impact

Le paramètre QUOTED_IDENTIFER est toujours défini sur ON pour les fonctions de table à instructions multiples lorsqu'elles sont créées indépendamment du paramètre de niveau de session.

Le paramètre de session QUOTED IDENTIFIER est respecté lorsque les fonctions de table à instructions multiples sont créées.

Moyenne

Lorsque vous créez ou altérez une fonction de partition, les littéraux datetime et smalldatetime dans la fonction sont évalués en supposant que US_English (Anglais États-Unis) est le paramètre de langue.

Le paramètre de langue actuel est utilisé pour évaluer les littéraux datetime et smalldatetime dans la fonction de partition.

Moyenne

La clause FOR BROWSE est autorisée (et ignorée) dans les instructions INSERT et SELECT INTO.

La clause FOR BROWSE n'est pas autorisée dans les instructions INSERT et SELECT INTO.

Moyenne

Les prédicats de texte intégral sont autorisés dans la clause OUTPUT.

Les prédicats de texte intégral ne sont pas autorisés dans la clause OUTPUT.

Faible

Les instructions CREATE FULLTEXT STOPLIST, ALTER FULLTEXT STOPLIST et DROP FULLTEXT STOPLIST ne sont pas prises en charge. La liste de mots vides système est associée automatiquement aux nouveaux index de recherche en texte intégral.

Les instructions CREATE FULLTEXT STOPLIST, ALTER FULLTEXT STOPLIST et DROP FULLTEXT STOPLIST sont prises en charge.

Faible

MERGE n'est pas appliqué comme mot clé réservé.

MERGE est un mot clé entièrement réservé. L'instruction MERGE est prise en charge sous les niveaux de compatibilité 100 et 90.

Faible

L'utilisation de l'argument <dml_table_source> de l'instruction INSERT déclenche une erreur de syntaxe.

Vous pouvez capturer les résultats d'une clause OUTPUT dans une instruction imbriquée INSERT, UPDATE, DELETE ou MERGE, puis les insérer dans une table ou une vue cible. Cette opération s'effectue en utilisant l'argument <dml_table_source> de l'instruction INSERT.

Faible

Sauf si l'option NOINDEX est spécifiée, DBCC CHECKDB ou DBCC CHECKTABLE effectue les vérifications de la cohérence physique et logique sur une seule table ou vue indexée et sur tous ses index non-cluster et XML. Les index spatiaux ne sont pas pris en charge.

DBCC CHECKDB ou DBCC CHECKTABLE effectue les vérifications de cohérence physique et logique sur une seule table et sur tous ses index non-cluster, sauf si l'option NOINDEX est spécifiée. Toutefois, seules des vérifications de cohérence physique sont effectuées par défaut sur les index XML, les index spatiaux et les vues indexées.

Si WITH EXTENDED_LOGICAL_CHECKS est spécifié, des vérifications logiques sont effectuées sur des vues indexées, des index XML et des index spatiaux, là où ils sont présents. Par défaut, les vérifications de cohérence physique sont effectuées avant les vérifications de cohérence logique. Si l'option NOINDEX est également spécifiée, seules les vérifications logiques sont effectuées.

Faible

Lorsqu'une clause OUTPUT est utilisée avec une instruction des langages de manipulation de données (DML) et une erreur d'exécution se produit pendant l'exécution d'instruction, la transaction complète est terminée et restaurée.

Lorsqu'une clause OUTPUT est utilisée avec une instruction DML (Data Manipulation Language) et qu'une erreur d'exécution se produit pendant l'exécution de l'instruction, le comportement est déterminé par le paramètre SET XACT_ABORT. Si SET XACT_ABORT a la valeur OFF, une erreur de l'abandon de l'instruction générée par l'instruction DML à l'aide de la clause OUTPUT met fin à l'instruction, mais l'exécution du lot continue et la transaction n'est pas restaurée. Si SET XACT_ABORT a la valeur ON, toutes les erreurs d'exécution générées par l'instruction DML à l'aide de la clause OUTPUT termineront le lot, et la transaction est restaurée.

Faible

CUBE et ROLLUP ne sont pas appliqués comme mots clé réservés.

CUBE et ROLLUP sont des mots clé réservés dans la clause GROUP BY.

Faible

La validation stricte est appliquée aux éléments du type anyType XML.

La validation libre est appliquée aux éléments du type anyType XML. Pour plus d'informations, consultez Composants génériques et validation de contenu.

Faible

Les attributs spéciaux xsi:nil et xsi:type ne peuvent pas être interrogés ou modifiés par les instructions des langages de manipulation de données.

Cela signifie que /e/@xsi:nil échoue alors que /e/@* ignore les attributs xsi:nil et xsi:type. Toutefois, /e retourne les attributs xsi:nil et xsi:type pour des raisons de cohérence avec SELECT xmlCol, même si xsi:nil = "false".

Les attributs spéciaux xsi:nil et xsi:type sont stockés comme attributs réguliers et peuvent être interrogés et modifiés.

Par exemple, l'exécution de la requête SELECT x.query('a/b/@*') retourne tous les attributs y compris xsi:nil et xsi:type. Pour exclure ces types dans la requête, remplacez @* par @*[namespace-uri(.) != "insert xsi namespace uri" et pas (local-name(.) = "type" ou local-name(.) ="nil".

Faible

Une fonction définie par l'utilisateur qui convertit une valeur de chaîne constante XML en un type datetime SQL Server est marquée comme déterministe.

Une fonction définie par l'utilisateur qui convertit une valeur de chaîne constante XML en un type datetime SQL Server est marquée comme non déterministe. 

Faible

Les types de liste et d'union XML ne sont pas pris en charge complètement.

Les types de liste et d'union sont complètement pris en charge ainsi que les fonctionnalités suivantes :

  • Union de liste

  • Union d'union

  • Liste de types atomiques

  • Liste d'union

Faible

Les options SET requises pour une méthode xQuery ne sont pas validées lorsque la méthode est contenue dans une vue ou une fonction table incluse.

Les options SET requises pour une méthode xQuery sont validées lorsque la méthode est contenue dans une vue ou une fonction table incluse. Une erreur survient si les options SET de la méthode sont définies incorrectement.

Pour plus d'informations sur les paramètres d'option requis, consultez Définition des options (type de données XML).

Faible

Les valeurs d'attribut XML qui contiennent des caractères de fin de ligne (retour chariot et saut de ligne) ne sont pas normalisées selon la norme XML. Autrement dit, les deux caractères sont retournés à la place d'un caractère de saut de ligne unique.

Les valeurs d'attribut XML qui contiennent des caractères de fin de ligne (retour chariot et saut de ligne) sont normalisées selon la norme XML. Autrement dit, tous les sauts de ligne dans les entités analysées externes (y compris l'entité de document) sont normalisés à l'entrée en un caractère unique #xA par la traduction de la séquence de deux caractères #xD #xA et #xD qui n'est pas suivi de #xA.

Les applications qui utilisent des attributs pour transporter des valeurs de chaîne qui contiennent des caractères de fin de ligne ne recevront pas ces caractères en retour lorsqu'ils sont soumis. Pour éviter le processus de normalisation, utilisez les entités de caractère numérique XML pour encoder tous les caractères de fin de ligne.

Faible

Les propriétés de colonne ROWGUIDCOL et IDENTITY peuvent être nommées de manière incorrecte en tant que contrainte. Par exemple, l'instruction CREATE TABLE T (C1 int CONSTRAINT MyConstraint IDENTITY) s'exécute, mais le nom de contrainte n'est pas conservé et n'est pas accessible à l'utilisateur.

Les propriétés de colonne ROWGUIDCOL et IDENTITY ne peuvent pas être nommées en tant que contrainte. L'erreur 156 est retournée.

Faible

La mise à jour des colonnes en utilisant une affectation bidirectionnelle telle que UPDATE T1 SET @v = column_name = <expression> peut produire des résultats inattendus parce que la valeur vivante de la variable peut être utilisée dans d'autres clauses telles que la clause WHERE et ON pendant l'exécution d'instruction à la place de la valeur de départ de l'instruction. Cette opération peut modifier les significations des prédicats de façon imprévisible et ligne par ligne.

Ce comportement est applicable uniquement lorsque le niveau de compatibilité est défini à 90.

La mise à jour de colonnes en utilisant une affectation bidirectionnelle produit des résultats attendus car seule la valeur de départ d'instruction de la colonne fait l'objet d'un accès pendant l'exécution de l'instruction.

Faible

L'attribution de variable est autorisée dans une instruction contenant un opérateur UNION de niveau supérieur, celle-ci produit néanmoins des résultats inattendus. Par exemple, dans les instructions suivantes, la variable locale @v reçoit la valeur de la colonne EmployeeID issue de l'union de deux tables. Par définition, lorsque l'instruction SELECT retourne plusieurs valeurs, la dernière valeur retournée est affectée à la variable. Dans ce cas, la dernière valeur est attribuée correctement à la variable, toutefois, le jeu de résultats de l'instruction SELECT UNION est également retourné.

ALTER DATABASE AdventureWorks2008R2
SET compatibility_level = 90;
GO
USE AdventureWorks2008R2;
GO
DECLARE @v int;
SELECT @v = EmployeeID FROM HumanResources.Employee
UNION ALL
SELECT @v = EmployeeID FROM HumanResources.EmployeeAddress;
SELECT @v;

L'attribution de variable n'est pas autorisée dans une instruction contenant un opérateur UNION de niveau supérieur. L'erreur 10734 est retournée.

Pour résoudre l'erreur, réécrivez la requête, comme dans l'exemple suivant.

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

Faible

La fonction ODBC {fn CONVERT()} utilise le format de date par défaut de la langue. Pour certaines langues, le format par défaut est YDM, ce qui peut provoquer des erreurs de conversion lorsque CONVERT() est associé à d'autres fonctions, telles que {fn CURDATE ()}, qui attendent un format YMD.

La fonction ODBC {fn CONVERT()} utilise le style 121 (format YMD indépendant de la langue) lors de la conversion aux types de données ODBC SQL_TIMESTAMP, SQL_DATE, SQL_TIME, SQLDATE, SQL_TYPE_TIME et SQL_TYPE_TIMESTAMP.

Faible

La fonction ODBC {fn CURDATE()} retourne uniquement la date au format 'YYYY-MM-DD'.

La fonction ODBC {fn CURDATE ()} retourne la date et l'heure à la fois, par exemple 'YYYY-MM-DD hh:mm:ss.

Faible

Les intrinsèques datetime tels que DATEPART ne requièrent pas que les valeurs d'entrée de chaîne soient des littéraux datetime valides. Par exemple, SELECT DATEPART (année, '2007/05-30') compile correctement.

Les intrinsèques datetime tels que DATEPART requièrent que les valeurs d'entrée de chaîne soient des littéraux datetime valides. L'erreur 241 est retournée lorsqu'un littéral datetime non valide est utilisé.

Faible

Mots clés réservés

Le paramètre de compatibilité détermine aussi les mots clés réservés par le Moteur de base de données. Le tableau suivant illustre les mots clés réservés introduits par chacun des niveaux de compatibilité.

Paramètre de niveau de compatibilité

Mots clés réservés

100

CUBE, MERGE, ROLLUP

90

EXTERNAL, PIVOT, UNPIVOT, REVERT, TABLESAMPLE

80

COLLATE, FUNCTION, OPENXML

À un niveau de compatibilité spécifique, les mots clés réservés incluent l'ensemble des mots clés introduits à partir de ce niveau ou sous celui-ci. Ainsi, pour les applications au niveau 100, par exemple, l'ensemble des mots clés répertoriés dans le tableau précédent sont réservés. À des niveaux de compatibilité inférieurs, les mots clés de niveau 100 demeurent des noms d'objet valides, mais les fonctions de langage de niveau 100 correspondant à ces mots clés sont indisponibles.

Une fois introduit, un mot clé demeure réservé. Le mot clé réservé OPENXML, par exemple, introduit au niveau de compatibilité 80, est également réservé aux niveaux 90 et 100.

Si une application utilise un identificateur réservé en tant que mot clé pour son niveau de compatibilité, l'application échoue. Pour contourner ce problème, placez l'identificateur entre crochets ([ ]) ou entre guillemets (" ") ; par exemple, pour effectuer la mise à niveau d'une application utilisant l'identificateur EXTERNAL au niveau de compatibilité 90, vous pouvez modifier l'identificateur de la manière suivante : [EXTERNAL] ou "EXTERNAL".

Pour plus d'informations, consultez Mots clés réservés (Transact-SQL).

Autorisations

Requiert l'autorisation ALTER sur la base de données.

Exemples

A. Modification du niveau de compatibilité

L'exemple suivant remplace le niveau de compatibilité de la base de données AdventureWorks2008R2 par 90, SQL Server 2005.

ALTER DATABASE AdventureWorks2008R2
SET COMPATIBILITY_LEVEL = 90;
GO

B. Effet du niveau de compatibilité sur ORDER BY (scénario 1)

L'exemple suivant illustre la différence dans la liaison ORDER BY pour les niveaux de compatibilité 80 et 100. Cet exemple illustre la création d'un exemple de table, SampleTable, dans la base de données tempdb.

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

Dans le niveau de compatibilité 90 et supérieur, celui par défaut, l'instruction SELECT... ORDER BY suivante produit une erreur car l'alias de colonne dans la clause AS, c1, est ambigu.

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

Après la redéfinition de la base de données avec le niveau de compatibilité 80, la même instruction SELECT... ORDER BY réussit.

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

L'instruction SELECT... ORDER BY suivante fonctionne dans les deux niveaux de compatibilité parce qu'un alias non équivoque est spécifié dans la clause AS.

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

C. Effet du niveau de compatibilité sur ORDER BY (scénario 2)

Dans le niveau de compatibilité 90 et supérieur, celui par défaut, l'instruction SELECT...ORDER BY suivante produit une erreur car l'alias de colonne spécifié dans la clause ORDER BY contient un préfixe de table.

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

Après la redéfinition de la base de données avec le niveau de compatibilité 80, la même instruction SELECT...ORDER BY réussit.

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

L'instruction SELECT...ORDER BY suivante fonctionne dans les deux niveaux de compatibilité parce que le préfixe de table a été supprimé de l'alias de colonne spécifié dans la clause 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