MODIFIER le niveau de compatibilité de la base de données (Transact-SQL)

 

CETTE RUBRIQUE S’APPLIQUE À :ouiSQL Server (à partir de la version 2008)ouiAzure SQL DatabasenonAzure SQL Data WarehousenonParallel Data Warehouse

Définit certains comportements de base de données pour qu'ils soient compatibles avec la version de SQL Server spécifiée. Pour les autres options ALTER DATABASE, consultez la page ALTER DATABASE (Transact-SQL).

Topic link icon Conventions de la syntaxe Transact-SQL

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

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

COMPATIBILITY_LEVEL {130 | 120 | 110 | 100 | 90 | 80}
Version de SQL Server avec laquelle la base de données doit être compatible. Les valeurs de niveau de compatibilité suivants peuvent être configurés :

ProductVersion du moteur de base de donnéesDésignation de niveau de compatibilitéPrise en charge des valeurs de niveau de compatibilité
SQL Server vNext14140140, 130, 120, 110, 100
SQL Server 201613130130, 120, 110, 100
Base de données SQL12120130, 120, 110, 100
SQL Server 201412120120, 110, 100
SQL Server 201211110110, 100, 90
SQL Server 2008 R210.5105100, 90, 80
SQL Server 200810100100, 90, 80
SQL Server 200599090, 80
SQL Server 200088080
System_CAPS_ICON_note.jpg Remarque


Base de données SQL Azure V12 a été publiée en décembre 2014. Un aspect de cette version était que les nouvelles bases de données a eu leur niveau de compatibilité défini sur 120. En 2015 base de données SQL a changé sa prise en charge de niveau 130, bien que la valeur par défaut est restée 120.

À compter de mi-juin 2016, dans la base de données SQL Azure, le niveau de compatibilité par défaut sera 130 au lieu de 120 pour nouvellement créé bases de données. Bases de données créées avant mi-juin 2016 ne seront pas affectées et de conserveront leur niveau de compatibilité actuel (100, 110 ou 120).

Si vous souhaitez généralement d’un niveau 130 pour votre base de données, mais vous avez raison de préférer le niveau 110 estimation de cardinalité algorithme, consultez ALTER DATABASE étendue CONFIGURATION (Transact-SQL)et notamment son mot-clé LEGACY_CARDINALITY_ESTIMATION = ON.

Pour plus d’informations sur la manière d’évaluer les différences de performances de vos requêtes plus importants, entre deux niveaux de compatibilité de base de données SQL Azure, consultez amélioré les performances de requête avec 130 au niveau de compatibilité de base de données SQL Azure.

Exécutez la requête suivante pour déterminer la version de le Moteur de base de données que vous êtes connecté.

SELECT SERVERPROPERTY('ProductVersion');  

System_CAPS_ICON_note.jpg Remarque


Pas toutes les fonctionnalités qui varient selon le niveau de compatibilité sont pris en charge sur Base de données SQL.

Pour déterminer le niveau de compatibilité actuel, interrogez la compatibility_level colonne de sys.databases (Transact-SQL).

SELECT name, compatibility_level FROM sys.databases;  

Pour toutes les installations de SQL Server, le niveau de compatibilité par défaut est défini sur la version de la Moteur de base de données. Bases de données sont définies à ce niveau, sauf si la modèle base de données a un niveau de compatibilité inférieur. Lorsqu’une base de données est mise à niveau depuis une version antérieure de SQL Server, la base de données conserve son niveau de compatibilité existant s’il est au moins minimale autorisée pour cette instance de SQL Server. La mise à niveau une base de données avec un niveau de compatibilité inférieur au niveau autorisé, définit la base de données pour la compatibilité le plus bas niveau autorisée. 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, interrogez la compatibility_level colonne dans la sys.databases affichage catalogue.

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. À partir du mode de compatibilité 130, toutes les nouvelles requêtes plan affectant fonctionnalités ont été ajoutées uniquement pour le nouveau mode de compatibilité. Cela a été fait pour réduire le risque au cours des mises à niveau qui résultent d’une dégradation des performances en raison de modifications de plan de requête. Du point de vue de l’application, l’objectif est toujours être le dernier niveau de compatibilité pour hériter parmi les nouvelles fonctionnalités ainsi que des améliorations des performances dans l’espace d’optimiseur de requête mais faire d’une façon contrôlée. 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. Pour plus d’informations, consultez les meilleures pratiques plus loin dans l’article de la mise à niveau.

Si existant SQL Server applications sont affectées par les différences de comportement dans la version de SQL Server, convertir l’application fonctionne en toute transparence avec le nouveau mode de compatibilité. Utilisez ensuite ALTER DATABASE pour modifier le niveau de compatibilité à 130. Le nouveau paramètre de compatibilité d’une base de données prend effet quand un USE Database émis ou une nouvelle connexion est traitée avec cette base de données comme base de données par défaut.

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 la page ALTER DATABASE (Transact-SQL).

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.

Cette section décrit les nouveaux comportements introduits avec le niveau de compatibilité 140.
Clients en cours d’exécution dans ce niveau d’obtenir les dernières fonctionnalités de langage et requête comportements optimiseur (y compris les modifications dans chaque version préliminaire par Microsoft).

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

Paramètre de niveau de compatibilité inférieur ou égal à 120Paramètre de niveau de compatibilité de 130
L’insertion dans une instruction Insert-select est monothread.L’insertion dans une instruction Insert-select est multithread ou peut avoir un plan parallèle.
Requêtes sur une table optimisée en mémoire exécutant monothread.Requêtes sur une table optimisée en mémoire peuvent désormais avoir des plans parallèles.
A introduit l’estimateur de cardinalité de 2014 SQL CardinalityEstimationModelVersion = « 120 »Planifier des améliorations de l’estimation avec le 130 de modèle Estimation de cardinalité qui est visible à partir d’une requête cardinalité supplémentaire. CardinalityEstimationModelVersion = « 130 »
Mode de traitement par lots ou en Mode ligne change avec des index Columnstore

Effectue un tri sur une table avec index Columnstore est en mode ligne

Agrégats de fonction de fenêtrage fonctionnent en mode de ligne telles que le retard ou prospect

Requêtes sur les tables Columnstore avec plusieurs clauses distinctes en mode ligne

Requêtes qui s’exécutent sous MAXDOP 1 ou avec un plan en série exécutée en mode ligne
Mode de traitement par lots ou en Mode ligne change avec des index Columnstore

Effectue un tri sur une table avec un index Columnstore est maintenant en mode batch

Agrégats de fenêtrage maintenant fonctionnent en mode de traitement par lots telles que le retard ou responsable

Les requêtes sur les tables Columnstore avec plusieurs clauses distinctes fonctionnent en mode Batch

Les requêtes en cours d’exécution sous Maxdop1 ou avec un plan en série s’exécutent en Mode Batch
Les statistiques peuvent être mis à jour automatiquement.La logique qui met à jour automatiquement des statistiques est plus agressive sur des tables volumineuses. Dans la pratique, cela doit réduire les cas où les clients ont reçu des problèmes de performances sur les requêtes où les lignes récemment insérées sont interrogés fréquemment, mais où les statistiques n'avaient pas été mis à jour pour inclure les valeurs.
Trace 2371 est désactivé par défaut dans SQL Server 2014.Trace 2371 est activé par défaut dans SQL Server 2016. Indicateur de trace 2371 indique à la mise à jour de statistiques automatiques pour échantillonner un sous-ensemble plus petit encore plus sage de lignes dans une table qui comporte un grand nombre de lignes.
 
Une amélioration consiste à inclure dans l’exemple plus de lignes qui ont été récemment insérées.
 
Une autre amélioration est de laisser les requêtes à s’exécuter pendant le processus de mise à jour des statistiques est en cours d’exécution, et non bloquant la requête.
Pour le niveau 120, statistiques échantillonnées par un seul-threads de processus.Niveau 130, statistiques échantillonnées par un multi-threads de processus.
les clés étrangères&253; entrants correspond à la limite.Une table donnée peut être référencée par des clés étrangères entrantes jusqu'à 10 000 ou références similaire. Pour connaître les restrictions associées, consultez Create Foreign Key Relationships.
Les algorithmes de hachage MD2, MD4, MD5, SHA et SHA1 déconseillées sont autorisés.Seuls les algorithmes de hachage SHA2_256 et SHA2_512 sont autorisées.

Correctifs sous trace indicateur 4199 dans les versions antérieures de SQL Server antérieures à SQL Server 2016 sont désormais activé par défaut. Avec le mode de compatibilité 130. Indicateur de trace 4199 sera applicable pour les nouveaux correctifs d’optimiseur de requête sont libérés après SQL Server 2016. Pour utiliser l’ancien optimiseur de requête dans Base de données SQL vous devez sélectionner le niveau de compatibilité 110. Pour plus d’informations sur 4199 d’indicateur de Trace, consultez 4199 d’indicateur de Trace.

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

Paramètre de niveau de compatibilité inférieur ou égal à 110Paramètre de niveau de compatibilité égal à 120
L'ancien optimiseur de requête est utilisé.SQL Server 2014 inclut des améliorations appréciables dans le composant qui crée et optimise les plans de requête. Cette nouvelle fonctionnalité de l'optimiseur de requête dépend de l'utilisation du niveau de compatibilité 120 de la base de données. Pour bénéficier de ces améliorations, vous devez développer des applications de base de données à l'aide d'un niveau de compatibilité de base de données 120. Les applications qui sont migrées des versions antérieures de SQL Server doivent être soigneusement testées pour vérifier que de bonnes performances sont conservées ou améliorées. Si les performances se dégradent, définissez le niveau de compatibilité 110 ou inférieur de base de données pour utiliser la méthodologie de l'ancien optimiseur de requête.

Le niveau de compatibilité 120 de la base de données utilise un nouvel estimateur de cardinalité qui est réglé pour le stockage des données et les charges de travail OLTP modernes. Avant de définir le niveau de compatibilité de base de données à 110 en raison de problèmes de performances, consultez les recommandations de la section Plans de requête de la SQL Server 2014 nouvelles fonctionnalités de moteur de base de données rubrique.
Dans les niveaux de compatibilité inférieurs à 120, le paramètre de langue est ignoré lorsque vous convertissez un date à une valeur de chaîne. Notez que ce comportement est spécifique à la date type. Consultez l’exemple B dans la section exemples ci-dessous.Le paramètre de langue n’est pas ignoré lors de la conversion d’un date à une valeur de chaîne.
Les références récursives dans la partie droite d'une clause EXCEPT créent une boucle infinie. L’exemple C dans la section exemples ci-dessous illustre ce comportement.Les références récursives dans une clause EXCEPT génèrent une erreur conformément à la norme SQL ANSI.
Une expression CTE récursive autorise les noms de colonnes en double.Les expressions CTE récursives n'autorisent pas les noms de colonnes en double.
Les déclencheurs désactivés sont activés en cas de modifications.La modification d'un déclencheur ne modifie pas son état (activé ou désactivé).
La clause de table OUTPUT INTO ignore le paramètre IDENTITY_INSERT SETTING = OFF et permet l'insertion de valeurs explicites.Il est impossible d'insérer des valeurs explicites dans une colonne identité de table quand IDENTITY_INSERT a la valeur OFF.
Lorsque la relation contenant-contenu de base de données a la valeur partielle, la validation du champ $action dans la clause OUTPUT d'une instruction MERGE peut retourner une erreur de classement.Le classement des valeurs retournées par la clause $action d'une instruction MERGE est le classement de la base de données à la place du classement du serveur et aucune erreur de conflit de classement n'est retournée.
A SELECT INTO toujours instruction crée une opération d’insertion monothread.A SELECT INTO instruction peut créer une opération d’insertion parallèle. Lors de l'insertion d'un grand nombre de lignes, l'opération parallèle peut améliorer les performances.

Cette section décrit les nouveaux comportements introduits avec le niveau de compatibilité 110. Cette section s'applique également au niveau 120.

Paramètre de niveau de compatibilité inférieur ou égal à 100Paramètre de niveau de compatibilité d'au moins 110
Les objets de base de données CLR (Common Language Runtime) sont exécutés avec la version 4 du CLR. Toutefois, quelques changements de comportement introduits dans la version 4 du CLR sont évités. Pour plus d’informations, consultez Nouveautés de l’intégration du CLR.Les objets de base de données CLR sont exécutés avec la version 4 du CLR.
Les fonctions XQuery longueur de chaîne et sous-chaîne compte chaque caractère de substitution comme deux caractères.Les fonctions XQuery longueur de chaîne et sous-chaîne compte chaque caractère comme un caractère de substitution.
PIVOT est autorisé dans une requête d'expression de table commune récursive. Cependant, la requête retourne des résultats incorrects lorsqu'il existe plusieurs lignes par regroupement.PIVOT n'est pas autorisé dans une requête d'expression de table commune récursive. Une erreur est retournée.
L'algorithme RC4 est uniquement pris en charge pour des raisons de compatibilité descendante. Le nouveau matériel ne peut être chiffré à l'aide de RC4 ou de RC4_128 que lorsque la base de données se trouve dans le niveau de compatibilité 90 ou 100. (Non recommandé.) Dans SQL Server 2012, le matériel chiffré à l’aide de RC4 ou RC4_128 peut être déchiffré dans n’importe quel niveau de compatibilité.Le nouveau matériel ne peut pas être chiffré à l'aide de RC4 ou RC4_128. Utilisez à la place un algorithme plus récent, tel qu'un des algorithmes AES. Dans SQL Server 2012, le matériel chiffré à l’aide de RC4 ou RC4_128 peut être déchiffré dans n’importe quel niveau de compatibilité.
Le style par défaut pour les opérations CAST et CONVERT sur temps et datetime2 des types de données est 121, sauf si des types sont utilisé dans une expression de colonne calculée. Pour les colonnes calculées, le style par défaut est 0. Ce comportement influe sur les colonnes calculées lorsqu'elles sont créées, utilisées dans des requêtes impliquant le paramétrage automatique, ou utilisées dans des définitions de contraintes.

Exemple D dans la section exemples ci-dessous montre la différence entre les styles 0 et 121. Il ne présente pas le comportement décrit ci-dessus. Pour plus d’informations sur les styles de date et d’heure, consultez CAST et CONVERT (Transact-SQL).
Niveau de compatibilité est 110, le style par défaut pour les opérations CAST et CONVERT sur temps et datetime2 des types de données est toujours 121. Si votre requête repose sur l'ancien comportement, utilisez un niveau de compatibilité inférieur à 110, ou spécifiez explicitement le style 0 dans la requête affectée.

La mise à niveau de la base de données vers le niveau de compatibilité 110 ne modifie pas les données utilisateur stockées sur le disque. Vous devez corriger manuellement ces données comme il convient. Par exemple, si vous avez utilisé SELECT INTO pour créer une table à partir d'une source qui contenait une expression de colonne calculée décrite ci-dessus, les données (utilisant le style 0) sont stockées à la place de la définition de colonne calculée. Vous devez mettre à jour manuellement ces données pour qu'elles correspondent au style 121.
Toutes les colonnes des tables distantes du type smalldatetime qui sont référencées dans une vue partitionnée sont mappées en datetime. Les colonnes correspondantes dans les tables locales (dans la même position ordinale dans la liste de sélection) doivent être de type datetime.Toutes les colonnes des tables distantes du type smalldatetime qui sont référencées dans une vue partitionnée sont mappées en smalldatetime. Les colonnes correspondantes dans les tables locales (dans la même position ordinale dans la liste de sélection) doivent être de type smalldatetime.

Après la mise à niveau en 110, la vue partitionnée distribuée échoue en raison d'une incompatibilité de type de données. Vous pouvez résoudre ce problème en modifiant le type de données dans la table distante en datetime ou en définissant la compatibilité au niveau de la base de données locale à 100 ou inférieure.
La fonction SOUNDEX implémente les règles suivantes :

(1) MAJUSCULE H ou W majuscules sont ignorés lors de la séparation de deux consonnes qui ont le même numéro dans le code SOUNDEX.

2) si les 2 premiers caractères de character_expression ont le même numéro dans le code SOUNDEX, les deux caractères sont inclus. Sinon, si un jeu de consonnes côte à côte ont le même numéro dans le code SOUNDEX, toutes sont exclues à l'exception de la première.
La fonction SOUNDEX implémente les règles suivantes :

(1) si les majuscules H ou W majuscules séparent deux consonnes qui ont le même numéro dans le code SOUNDEX, la consonne à droite est ignorée.

(2) si un jeu de consonnes de côte à côte ont le même nombre dans le code SOUNDEX, toutes sont exclues, sauf le premier.

 

Des règles supplémentaires peuvent entraîner des disparités entre les valeurs calculées par la fonction SOUNDEX et les valeurs calculées sous des niveaux de compatibilité précédents. Après la mise à niveau vers le niveau de compatibilité 110, vous pouvez être amené à reconstruire les index, les segments de mémoire ou les contraintes CHECK qui utilisent la fonction SOUNDEX. Pour plus d’informations, consultez SOUNDEX (Transact-SQL)

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

Paramètre de niveau de compatibilité égal à 90Paramètre de niveau de compatibilité égal à 100Possibilité 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 modifiez une fonction de partition, datetime et smalldatetime littéraux dans la fonction sont évalués en supposant que US_English comme paramètre de langue.Le paramètre de langue actuel est utilisé pour évaluer datetime et smalldatetime littéraux 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
Validation stricte est appliquée aux éléments du document XML anyType type.Validation de type lax est appliquée aux éléments de la anyType type. Pour plus d’informations, consultez composants génériques et Validation du contenu.Faible
Les attributs spéciaux xsi : nil et xsi : type ne peut pas être interrogés ou modifiés par les instructions de langage de manipulation de données.

Cela signifie que /e/@xsi:nil échoue alors que /e/@* ignore la xsi : nil et xsi : type attributs. Toutefois, /e retourne le xsi : nil et xsi : type attributs pour la cohérence de 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 peut être interrogé et modifié.

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 @* avec @*[namespace-uri(.) != " insérer uri d’espace de noms xsi " et non (local-name(.) = "type" oulocal-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.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
Consultez l’exemple E dans la section exemples ci-dessous.Consultez l’exemple F dans la section exemples ci-dessous.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
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

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
130Doit être déterminé.
120Aucun.
110WITHIN GROUP, TRY_CONVERT, SEMANTICKEYPHRASETABLE, SEMANTICSIMILARITYDETAILSTABLE, SEMANTICSIMILARITYTABLE
100CUBE, MERGE, ROLLUP
90EXTERNAL, PIVOT, UNPIVOT, REVERT, TABLESAMPLE

À 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 110, 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 110 correspondant à ces mots clés sont indisponibles.

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

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 deux crochets ([]) ou des guillemets (» «), par exemple, pour mettre à niveau une application qui utilise l’identificateur externe au niveau de compatibilité 90, vous pouvez modifier l’identificateur soit [EXTERNAL] ou « EXTERNAL ».

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

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

A. Modification du niveau de compatibilité

L’exemple suivant modifie le niveau de compatibilité de la AdventureWorks2012 une base de données 110, SQL Server 2012.

ALTER DATABASE AdventureWorks2012  
SET COMPATIBILITY_LEVEL = 110;  
GO  

L’exemple suivant retourne le niveau de compatibilité de la base de données actuelle.

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

B. En ignorant l’instruction SET LANGUAGE sauf avec le niveau de compatibilité 120

La requête suivante ignore l’instruction SET LANGUAGE sauf avec le niveau de compatibilité 120.

SET DATEFORMAT dmy;   
DECLARE @t2 date = '12/5/2011' ;  
SET LANGUAGE dutch;   
SELECT CONVERT(varchar(11), @t2, 106);   
  
-- Results when the compatibility level is less than 120.   
12 May 2011   
  
-- Results when the compatibility level is set to 120).  
12 mei 2011  

C.

Pour le paramètre de niveau de compatibilité inférieur ou égal à 110, les références récursives dans la partie droite d’une clause EXCEPT créent une boucle infinie.

WITH   
cte AS (SELECT * FROM (VALUES (1),(2),(3)) v (a)),  
r   
AS (SELECT a FROM Table1  
UNION ALL  
(SELECT a FROM Table1 EXCEPT SELECT a FROM r) )   
SELECT a   
FROM r;  
  

D.

Cet exemple montre la différence entre les styles 0 et 121. Pour plus d’informations sur les styles de date et d’heure, consultez CAST et 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  

E.

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 BusinessEntityID 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 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;  

F.

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 = BusinessEntityID FROM   
    (SELECT BusinessEntityID FROM HumanResources.Employee  
     UNION ALL  
     SELECT BusinessEntityID FROM HumanResources.EmployeeAddress) AS Test;  
SELECT @v;  

MODIFIER la base de données (Transact-SQL)
Mots clés réservés (Transact-SQL)
CRÉER la base de données (SQL Server Transact-SQL)
DATABASEPROPERTYEX (Transact-SQL)
Sys.Databases (Transact-SQL)
Sys.database_files (Transact-SQL)

Ajouts de la communauté

AJOUTER
Afficher: