Niveau de compatibilité ALTER DATABASE (Transact-SQL)

Article
06/20/2024

S’applique à : SQL Server Azure SQL Database Azure SQL Managed Instance

Définit Transact-SQL et des comportements de traitement des requêtes pour qu’ils soient compatibles avec la version spécifiée du moteur SQL. Pour connaître les autres options d’ALTER DATABASE, voir ALTER DATABASE.

Pour plus d’informations sur les conventions de la syntaxe, consultez Conventions de la syntaxe Transact-SQL.

Syntaxe

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

Arguments

database_name

Nom de la base de données à modifier.

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

Version de SQL Server avec laquelle la base de données doit devenir compatible. Les valeurs de niveau de compatibilité suivantes peuvent être configurées (toutes les versions ne prennent pas en charge l’ensemble des niveaux de compatibilité listés ci-dessus) :

Produit	Version du moteur de base de données	Désignation du niveau de compatibilité par défaut	Valeurs de niveau de compatibilité prises en charge
Azure SQL Database	16	160	160, 150, 140, 130, 120, 110, 100
Azure SQL Managed Instance	16	150	160, 150, 140, 130, 120, 110, 100
SQL Server 2022 (16.x)	16	160	160, 150, 140, 130, 120, 110, 100
SQL Server 2019 (15.x)	15	150	150, 140, 130, 120, 110, 100
SQL Server 2017 (14.x)	14	140	140, 130, 120, 110, 100
SQL Server 2016 (13.x)	13	130	130, 120, 110, 100
SQL Server 2014 (12.x)	12	120	120, 110, 100
SQL Server 2012 (11.x)	11	110	110, 100, 90
SQL Server 2008 R2 (10.50.x)	10.5	100	100, 90, 80
SQL Server 2008 (10.0.x)	10	100	100, 90, 80
SQL Server 2005 (9.x)	9	90	90, 80
SQL Server 2000 (8.x)	8	80	80

Important

Les numéros de version du moteur de base de données pour SQL Server et Azure SQL Database ne sont pas comparables les uns aux autres. Il s’agit plutôt de numéros de build internes pour ces produits distincts. Le moteur de base de données pour Azure SQL Database repose sur la même base de code que le moteur de base de données SQL Server. Plus important encore, le moteur de base de données dans Azure SQL Database a toujours les bits les plus récents du moteur de base de données SQL. La version 12 de Azure SQL Database est plus récente que la version 15 de SQL Server.

Meilleures pratiques de mise à niveau du niveau de compatibilité de la base de données

Pour connaître le workflow recommandé pour la mise à niveau du niveau de compatibilité, consultez Maintenir la stabilité des performances lors de la mise à niveau vers une version plus récente de SQL Server. En outre, pour une expérience assistée avec la mise à niveau du niveau de compatibilité de base de données, consultez Mise à niveau de bases de données à l’aide de l’Assistant Paramétrage de requêtes.

Notes

Pour toutes les installations de SQL Server, le niveau de compatibilité par défaut est associé à la version du Moteur de base de données. Ce niveau est attribué aux nouvelles bases de données, sauf si la base de données model a un niveau de compatibilité inférieur. Pour les bases de données attachées ou restaurées à partir d’une version antérieure de SQL Server, la base de données conserve son niveau de compatibilité existant si celui-ci correspond au moins à la valeur minimale autorisée pour cette instance de SQL Server. Le déplacement d’une base de données ayant un niveau de compatibilité inférieur à celui autorisé par le Moteur de base de données a pour effet de lui attribuer automatiquement le niveau de compatibilité autorisé le plus bas. Cela s'applique aussi bien aux bases de données système qu'aux bases de données utilisateur.

Les comportements suivants sont attendus pour SQL Server 2017 (14.x) lorsqu’une base de données est attachée ou restaurée, et après une mise à niveau sur place :

Si le niveau de compatibilité d'une base de données utilisateur est à 100 ou supérieur avant la mise à niveau, il reste le même après la mise à niveau.
Si le niveau de compatibilité d’une base de données utilisateur était à 90 avant la mise à niveau, dans la base de données mise à niveau, le niveau de compatibilité est défini à 100, ce qui correspond au niveau de compatibilité le plus bas pris en charge dans SQL Server 2017 (14.x).
Les niveaux de compatibilité des bases de données tempdb, model, msdb et Resource sont définis sur le niveau de compatibilité par défaut d’une version donnée du Moteur de base de données.
La base de données système master conserve le niveau de compatibilité qu'elle avait avant la mise à niveau. Cela n’a pas d’incidence sur le comportement de la base de données utilisateur.

Concernant les bases de données déjà exécutées avec un faible niveau de compatibilité, il est pertinent de conserver ce niveau de compatibilité tant que l’application n’a pas besoin de tirer parti des améliorations disponibles uniquement dans un niveau plus élevé de compatibilité de la base de données. Pour chaque nouvelle tâche de développement ou quand une application existante exige le recours à de nouvelles fonctionnalités comme le Traitement de requêtes intelligent ou du nouveau code Transact-SQL, prévoyez de mettre à niveau le niveau de compatibilité de la base de données vers la dernière version disponible. Pour plus d’informations, consultez Niveaux de compatibilité et mises à niveau du moteur de base de données.

Notes

S’il n’y a pas ni objets utilisateur ni dépendances, il est généralement sûr de mettre à niveau vers le niveau de compatibilité par défaut. Pour plus d’informations, consultez Recommandations – base de données MASTER.

Utilisez ALTER DATABASE pour modifier le niveau de compatibilité de la base de données. Le nouveau paramètre de compatibilité d’une base de données prend effet à partir du moment où une commande USE <database> est émise ou qu’un nouveau compte de connexion est traité avec cette base de données définie comme contexte de base de données par défaut.

Pour voir le niveau de compatibilité actuel d’une base de données, interrogez la colonne compatibility_level dans la vue de catalogue sys.databases.

Une base de données de distribution créée dans une version antérieure de SQL Server et mise à niveau vers SQL Server 2016 (13.x) RTM ou Service Pack 1 présente un niveau de compatibilité de 90, qui n’est pas pris en charge pour les autres bases de données. La fonctionnalité de réplication ne s’en trouve pas affectée. Une mise à niveau vers des Service Packs et des versions ultérieures de SQL Server se traduit par une élévation du niveau de compatibilité de la base de données de distribution pour atteindre celui de la base de données master.

Pour utiliser un niveau de compatibilité d’au moins 120 pour l’intégralité d’une base de données tout en adhérant au modèle d’estimation de la cardinalité de SQL Server 2012 (11.x), qui correspond au niveau de compatibilité de la base de données 110, consultez ALTER DATABASE SCOPED CONFIGURATION et en particulier son mot clé LEGACY_CARDINALITY_ESTIMATION = ON.

Remarques pour Azure SQL

Le niveau de compatibilité par défaut est SQL Server 2022 (160) pour les bases de données nouvellement créées dans Azure SQL Database.

Le niveau de compatibilité par défaut est SQL Server 2019 (150) pour les bases de données nouvellement créées dans Azure SQL Managed Instance.

Microsoft ne met pas automatiquement à jour le niveau de compatibilité des bases de données pour les bases de données existantes. Il incombe aux clients de le faire à leur convenance.

Microsoft recommande vivement aux clients d’envisager de passer au dernier niveau de compatibilité afin d’utiliser les dernières améliorations apportées à l’optimisation des requêtes. Pour obtenir des conseils sur l’évaluation des différences de performances de vos requêtes les plus importantes entre deux niveaux de compatibilité différents sur Azure SQL Database, consultez Amélioration des performances des requêtes avec le niveau de compatibilité 130 dans Azure SQL Database. Cet article fait référence au niveau de compatibilité 130 et à SQL Server, mais la même méthodologie s’applique pour passer au niveau 140 ou à des niveaux supérieurs dans SQL Server et Azure SQL Database.

Notez que Azure SQL Database ne prend pas en charge l’intégralité des fonctionnalités disponibles avec les différents niveaux de compatibilité.

Rechercher le niveau de compatibilité actuel

Pour déterminer le niveau de compatibilité actuel, interrogez la colonne compatibility_level de sys.databases.

SELECT name, compatibility_level FROM sys.databases;

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

SELECT SERVERPROPERTY('ProductVersion');

Niveaux de compatibilité et mises à niveau du Moteur de base de données

Le niveau de compatibilité de la base de données constitue un outil précieux quand il s’agit de moderniser une base de données. Il permet de mettre à niveau le Moteur de base de données SQL Server tout en maintenant le même état opérationnel pour connecter des applications, car il conserve le niveau de compatibilité de la base de données antérieur à la mise à niveau. Cela signifie qu’il est possible de procéder à une mise à niveau à partir d’une version antérieure de SQL Server (telle que SQL Server 2008 (10.0.x)) vers SQL Server ou Azure SQL Database (avec Azure SQL Managed Instance) sans aucune modification de l’application (à l’exception de la connectivité de base de données). Pour plus d’informations, consultez Certification de compatibilité.

Tant que l’application n’a pas besoin de tirer parti des améliorations disponibles uniquement dans un niveau plus élevé de compatibilité de la base de données, il est pertinent de mettre à niveau le Moteur de base de données SQL Server et de conserver le niveau de compatibilité précédent. Pour plus d’informations sur l’utilisation du niveau de compatibilité pour la compatibilité descendante, consultez Certification de compatibilité.

Niveaux de compatibilité et procédures stockées

Lors de son exécution, une procédure stockée utilise le niveau de compatibilité actuel 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.

Utilisation du niveau de compatibilité pour la compatibilité descendante

Le paramètre niveau de compatibilité de la base de données fournit une compatibilité descendante avec les versions antérieures de SQL Server en ce qui concerne Transact-SQL et les comportements d’optimisation des requêtes, uniquement pour la base de données spécifiée, et non pour l’ensemble du serveur.

À partir du mode de compatibilité 130, les nouveaux plans de requête affectant les correctifs et les fonctionnalités ne sont ajoutés intentionnellement qu’au nouveau niveau de compatibilité. Lors des mises à niveau, cela permet de réduire les risques liés à la dégradation des performances en raison des modifications du plan de requête potentiellement introduites par de nouveaux comportements d’optimisation des requêtes.

Du point de vue de l’application, utilisez le niveau de compatibilité le plus bas comme chemin de migration plus sûr pour contourner les problèmes liés aux différences de versions dans les comportements qui sont contrôlés par le paramètre de niveau de compatibilité approprié. L’objectif doit toujours être de procéder à une mise à niveau vers le niveau de compatibilité le plus récent à un moment donné, de façon à hériter de certaines nouvelles fonctionnalités comme le traitement de requêtes intelligent, mais cette opération doit être effectuée de façon contrôlée.

Pour plus d’informations, notamment sur le workflow recommandé pour mettre à niveau le niveau de compatibilité de la base de données, consultez Meilleures pratiques de mise à niveau du niveau de compatibilité de la base de données.

Les fonctionnalités obsolètes obtenues précédemment via une version de SQL Server ne sont pas protégées par le niveau de compatibilité. Il s’agit des fonctionnalités qui ont été supprimées du Moteur de base de données SQL Server. Par exemple, l’indicateur FASTFIRSTROW a été abandonné dans SQL Server 2012 (11.x), et remplacé par l’indicateur OPTION (FAST n ). Le fait de définir le niveau de compatibilité de la base de données sur 110 ne permet pas de restaurer l’indicateur obsolète. Pour plus d’informations sur la fonctionnalité dépréciée, consultez Fonctionnalité du moteur de base de données supprimée dans SQL Server.
Les modifications cassants introduites dans une version de SQL Server donnée peuvent ne pas être protégées par le niveau de compatibilité. Il s’agit des changements de comportement entre les versions du Moteur de base de données SQL Server. Le comportement Transact-SQL est généralement protégé par le niveau de compatibilité. Toutefois, les objets système modifiés ou supprimés ne sont pas protégés par le niveau de compatibilité.

Un exemple de modification cassant protégée par le niveau de compatibilité est une conversion implicite de datetime en types de données datetime2. Avec le niveau de compatibilité de base de données 130, il offre une meilleure précision en prenant en compte les fractions de milliseconde, ce qui génère différentes valeurs converties. Pour restaurer l’ancien comportement de conversion, définissez le niveau de compatibilité de la base de données sur 120 ou sur une valeur inférieure.

Parmi les changements importants non protégés par le niveau de compatibilité figurent :
- Les noms de colonne modifiés dans les objets système. Dans SQL Server 2012 (11.x), la colonne single_pages_kb de sys.dm_os_sys_info a été renommée pages_kb. Quel que soit le niveau de compatibilité, la requête SELECT single_pages_kb FROM sys.dm_os_sys_info génère l’erreur 207 (nom de colonne non valide).
- Les objets système supprimés. Dans SQL Server 2012 (11.x), sp_dboption a été supprimé. Quel que soit le niveau de compatibilité, l’instruction EXEC sp_dboption 'AdventureWorks2022', 'autoshrink', 'FALSE'; génère l’erreur 2812 (Couldn't find stored procedure 'sp_dboption').
Pour plus d’informations sur les changements cassants, consultez Changements cassants dans les fonctionnalités du moteur de base de données de SQL Server 2019, Changements cassants dans les fonctionnalités du moteur de base de données de SQL Server 2017, Changements cassants dans les fonctionnalités du moteur de base de données de SQL Server 2016 et Changements cassants dans les fonctionnalités du moteur de base de données de SQL Server 2014.

Comparaison entre les niveaux de compatibilité

Pour toutes les installations de SQL Server, le niveau de compatibilité par défaut est associé à la version du Moteur de base de données, comme vous pouvez le voir dans ce tableau. Pour chaque nouvelle tâche de développement, prévoyez toujours de certifier les applications avec le tout dernier niveau de compatibilité de la base de données.

La nouvelle syntaxe Transact-SQL n’est pas contrôlée par le niveau de compatibilité de la base de données, sauf si elle risque de créer un conflit avec le code utilisateur Transact-SQL et ainsi d’empêcher les applications existantes de fonctionner. Ces exceptions sont documentées dans les sections suivantes de cet article qui décrivent les différences qui existent entre chaque niveau de compatibilité.

Le niveau de compatibilité de base de données offre également une compatibilité descendante avec les versions antérieures de SQL Server, car les bases de données attachées ou restaurées à partir de n’importe quelle version antérieure de SQL Server conservent leur niveau de compatibilité existant (si celui-ci est identique ou supérieur au niveau de compatibilité minimal autorisé). Ceci a été abordé dans la section Utilisation du niveau de compatibilité pour la compatibilité descendante de cet article.

À partir du niveau 130 de compatibilité de la base de données, les nouveaux correctifs et nouvelles fonctionnalités qui ont une incidence sur les plans de requête ne sont ajoutés qu’au dernier niveau de compatibilité disponible, également appelé « niveau de compatibilité par défaut ». Lors des mises à niveau, cela permet de réduire les risques liés à la dégradation des performances en raison des modifications du plan de requête potentiellement apportées par de nouveaux comportements d’optimisation des requêtes.

Les principales modifications qui affectent le plan et qui sont ajoutées uniquement au niveau de compatibilité par défaut d’une nouvelle version du Moteur de base de données sont les suivantes :

Les correctifs de l’optimiseur de requête publiés pour les versions précédentes de SQL Server sous l’indicateur de trace 4199 sont automatiquement activés avec le niveau de compatibilité par défaut d’une version plus récente de SQL Server .

S’applique à : SQL Server (à partir de la version SQL Server 2016 (13.x)), Azure SQL Database.

Par exemple, lorsque SQL Server 2016 (13.x) est sorti, tous les correctifs de l’optimiseur de requête publiés pour les versions précédentes de SQL Server (et les niveaux de compatibilité de 100 à 120) étaient activés automatiquement pour les bases de données qui utilisaient le niveau de compatibilité par défaut (130) de SQL Server 2016 (13.x). Seuls les correctifs post-RTM de l’optimiseur de requête doivent être activés explicitement.

Pour activer les correctifs de l’optimiseur de requête, vous pouvez utiliser les méthodes suivantes :

Au niveau du serveur, avec l’indicateur de trace 4199.
Au niveau de la base de données, avec l’option QUERY_OPTIMIZER_HOTFIXES dans ALTER DATABASE SCOPED CONFIGURATION (Transact-SQL).
Au niveau de la requête, avec l’indicateur de requête USE HINT 'ENABLE_QUERY_OPTIMIZER_HOTFIXES' en modifiant la requête.
Au niveau de la requête, avec USE HINT 'ENABLE_QUERY_OPTIMIZER_HOTFIXES' sans modification du code, en utilisant la fonctionnalité Indicateur du Magasin des requêtes (préversion).

Plus tard, lorsque SQL Server 2017 (14.x) est sorti, tous les correctifs de l’optimiseur de requête publiés après la version RTM de SQL Server 2016 (13.x) étaient automatiquement activés pour les bases de données utilisant le niveau de compatibilité par défaut (140) de SQL Server 2017 (14.x). Il s’agit d’un comportement cumulatif qui inclut tous les correctifs des versions précédentes. Pour rappel, seuls les correctifs post-RTM de l’optimiseur de requête doivent être activés explicitement.

Le tableau suivant récapitule ce comportement :

Version du moteur de base de données	Niveau de compatibilité de la base de données	TF 4199	Modifications de l’optimiseur de requête de tous les précédents niveaux de compatibilité de base de données	Modifications de l’optimiseur de requête pour la version post-RTM du moteur de base de données
13 (SQL Server 2016 (13.x))	100 à 120 130	Off Il en va Off Il en va	Désactivé activé Activé activé	Désactivé activé Désactivé activé
14 (SQL Server 2017 (14.x))	100 à 120 130 140	Off Il en va Off Il en va Off Il en va	Désactivé activé Activé activé Activé activé	Désactivé activé Désactivé activé Désactivé activé
15 (SQL Server 2019 (15.x)) et 12 (Azure SQL Database)	100 à 120 130 à 140 150	Off Il en va Off Il en va Off Il en va	Désactivé activé Activé activé Activé activé	Désactivé activé Désactivé activé Désactivé activé
16 (SQL Server 2022 (16.x)) et 12 (Azure SQL Database)	100 à 120 130 à 150 160	Off Il en va Off Il en va Off Il en va	Désactivé activé Activé activé Activé activé	Désactivé activé Désactivé activé Désactivé activé

Les correctifs de l’optimiseur de requête qui résolvent les résultats erronés ou les erreurs relatives à des violations d’accès ne sont pas protégés par l’indicateur de trace 4199. Ces correctifs ne sont pas considérés comme facultatifs.

Les modifications apportées à l’estimateur de cardinalité sur SQL Server et Azure SQL Database sont activées uniquement pour le niveau de compatibilité par défaut d’une nouvelle version du Moteur de base de données , mais pas pour les niveaux de compatibilité précédents.

Par exemple, lorsque SQL Server 2016 (13.x) est sorti, les modifications apportées au processus d’estimation de la cardinalité étaient uniquement disponibles pour les bases de données utilisant le niveau de compatibilité par défaut (130) de SQL Server 2016 (13.x). Les niveaux de compatibilité précédents ont conservé le comportement d’estimation de la cardinalité qui était disponible avant SQL Server 2016 (13.x).

Plus tard, lorsque SQL Server 2017 (14.x) est sorti, les nouvelles modifications apportées au processus d’estimation de la cardinalité étaient uniquement disponibles pour les bases de données utilisant le niveau de compatibilité par défaut (140) de SQL Server 2017 (14.x). Le niveau de compatibilité de base de données 130 a conservé le comportement d’estimation de la cardinalité de SQL Server 2016 (13.x).

Le tableau suivant récapitule ce comportement :

Version du moteur de base de données	Niveau de compatibilité de la base de données	Nouvelles modifications apportées à la version CE
13 (SQL Server 2016 (13.x))	< 130 130	Désactivé activé
14 (SQL Server 2017 (14.x))¹	< 140 140	Désactivé activé
15 (SQL Server 2019 (15.x))¹	< 150 150	Désactivé activé
16 (SQL Server 2022 (16.x))¹	< 160 160	Désactivé activé

¹ Également applicable à Azure SQL Database.

Les sections suivantes de cet article abordent d’autres différences qui existent entre certains niveaux de compatibilité.

Différences entre le niveau de compatibilité 150 et le niveau 160

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

Paramètre de niveau de compatibilité inférieur ou égal à 150	Paramètre de niveau de compatibilité égal à 160
Les requêtes paramétrables ont un plan de requête unique basé sur les paramètres utilisés pour la première exécution. Un plan de requête unique est mis en cache et utilisé pour toutes les valeurs de paramètre. Un plan de requête peut alors devenir inefficace pour certaines valeurs du paramètre, également appelée plan sensible aux paramètres.	Les requêtes paramétrables peuvent présenter plusieurs plans de requête mis en cache pour différentes catégories de sélection d’un paramètre. L’optimisation du plan sensible aux paramètres est activée par défaut dans le niveau de compatibilité 160. Pour plus d’informations, consultez Optimisation du plan sensible aux paramètres.
L’estimation de la cardinalité utilise un seul ensemble par défaut d’hypothèses de modèle concernant les modèles de distribution et d’utilisation de données sous-jacents pour l’ensemble des bases de données et requêtes. L’unique manière de modifier et d’ajuster l’une de ces hypothèses consiste à lancer un processus manuel pour indiquer explicitement les hypothèses de modèle qui doivent être utilisées à l’aide d’indicateurs de requête. Aucun ajustement interne ne peut être apporté à ce modèle par défaut une fois qu’un plan de requête est généré.	L’estimation de la cardinalité commence par l’ensemble par défaut d’hypothèses de modèle concernant la distribution des données et les modèles d’utilisation sous-jacents. Toutefois, après quelques exécutions d’une requête donnée, le Moteur de base de données apprend quels ensembles d’hypothèses de modèle peuvent produire des estimations plus précises. Il ajuste par conséquent les hypothèses utilisées pour mieux correspondre au jeu de données interrogé. Les commentaires sur l’estimation de la cardinalité sont activés par défaut dans le niveau de compatibilité 160. Pour plus d’informations, consultez Commentaires sur l’estimation de la cardinalité.
Aucune détermination automatique du degré optimal de parallélisme n’est tentée par le Moteur de base de données. Pour plus d’informations sur le contrôle manuel du degré maximal de parallélisme (MAXDOP) sur l’instance, la base de données, la requête ou les niveaux de charge de travail, consultez Configuration du serveur : degré maximal de parallélisme	Les commentaires sur le degré de parallélisme (DOP) améliorent le niveau de performance des requêtes en identifiant les inefficacités du parallélisme pour les requêtes répétées, en fonction du temps écoulé et des attentes. Si l’utilisation du parallélisme est jugée inefficace, les commentaires DOP réduisent le DOP pour la prochaine exécution de la requête, quel que soit le DOP configuré et vérifie si cela a un effet positif. Les commentaires DOP ne sont pas activés par défaut. Pour activer les commentaires DOP, activez la configuration au niveau de la base de données `DOP_FEEDBACK` dans une base de données. Pour plus d’informations, consultez Commentaires sur le degré de parallélisme (DOP).

Différences entre le niveau de compatibilité 140 et le niveau 150

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

Paramètre de niveau de compatibilité inférieur ou égal à 140	Paramètre de niveau de compatibilité égal à 150
Les charges de travail relationnelles et analytiques peuvent ne pas être en mesure d’utiliser des index columnstore en raison d’une surcharge OLTP, d’un manque de prise en charge du fournisseur ou d’autres limitations. Sans les index columnstore, ces charges de travail ne peuvent pas bénéficier du mode d’exécution par lot,	Le mode d’exécution par lot est désormais disponible pour les charges de travail analytiques sans avoir besoin d’index columnstore. Pour plus d’informations, consultez mode batch sur rowstore.
Les requêtes en mode ligne qui demandent des tailles d’allocation de mémoire insuffisantes qui entraînent des déversements sur le disque peuvent continuer à rencontrer des problèmes lors d’exécutions consécutives.	Les requêtes en mode ligne qui demandent des tailles d’allocation de mémoire insuffisantes qui entraînent des débordements sur le disque peuvent avoir amélioré les performances des exécutions consécutives. Pour plus d’informations, consultez Rétroaction d’allocation de mémoire en mode ligne.
Les requêtes en mode ligne qui demandent une taille d’allocation de mémoire excessive qui entraînent des problèmes d’accès concurrentiel peuvent continuer à rencontrer des problèmes lors d’exécutions consécutives.	Les requêtes en mode ligne qui demandent une taille d’allocation de mémoire excessive qui entraînent des problèmes d’accès concurrentiel peuvent avoir amélioré la concurrence lors d’exécutions consécutives. Pour plus d’informations, consultez Rétroaction d’allocation de mémoire en mode ligne.
Les requêtes faisant référence à des fonctions scalaires définies par l’utilisateur T-SQL utilisent l’invocation itérative, ne disposent pas de l’évaluation des coûts et forcent l’exécution en série.	Les fonctions scalaires définies par l’utilisateur T-SQL sont transformées en expressions relationnelles équivalentes qui sont « placées inline » dans la requête appelante, ce qui entraîne souvent des gains de performances significatifs. Pour plus d’informations, consultez Incorporation des fonctions UDF scalaires T-SQL.
Les variables de table utilisent une estimation fixe pour l’estimation de la cardinalité. Si le nombre réel de lignes est nettement supérieur à la valeur devinée, les performances des opérations en aval peuvent être dégradées.	Les nouveaux plans utilisent la cardinalité réelle de la variable de table rencontrée à la première compilation, au lieu d’une estimation fixe. Pour plus d'informations, consultez compilation différée de variable de table.

Pour plus d’informations sur les fonctionnalités de traitement des requêtes activées dans le niveau de compatibilité de base de données 150, consultez Nouveautés de SQL Server 2019 et Traitement de requêtes intelligent dans les bases de données SQL.

Différences entre le niveau de compatibilité 130 et le niveau 140

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

Paramètre de niveau de compatibilité inférieur ou égal à 130	Paramètre de niveau de compatibilité égal à 140
Les estimations de cardinalité pour les instructions qui référencent des fonctions table à instructions multiples utilisent une estimation de ligne fixe.	Les estimations de cardinalité pour les instructions éligibles référençant des fonctions table à instructions multiples utilisent la cardinalité de la sortie de la fonction. Ceci peut être activé via l’exécution entrelacée pour les fonctions table à instructions multiples.
Les requêtes en mode Batch qui demandent des tailles d’allocation de mémoire insuffisantes qui entraînent des déversements sur le disque peuvent continuer à rencontrer des problèmes lors des exécutions consécutives.	Les requêtes en mode Batch qui demandent des tailles d’allocation de mémoire insuffisantes qui entraînent des déversements sur le disque peuvent avoir amélioré les performances des exécutions consécutives. Ceci est possible avec la rétroaction d’allocation de mémoire en mode batch, qui met à jour la taille de l’allocation de mémoire d’un plan mis en cache, si des dépassements se produisent pour les opérateurs en mode batch.
Les requêtes en mode Batch qui demandent une taille d’allocation de mémoire excessive qui entraînent des problèmes d’accès concurrentiel peuvent continuer à avoir des problèmes sur les exécutions consécutives.	Les requêtes en mode Batch qui demandent une taille d’octroi de mémoire excessive qui entraînent des problèmes d’accès concurrentiel peuvent avoir amélioré la concurrence lors d’exécutions consécutives. Ceci est possible avec la rétroaction d’allocation de mémoire en mode batch, qui met à jour la taille de l’allocation de mémoire d’un plan mis en cache, si une quantité excessive de mémoire a été demandée.
Les requêtes en mode batch qui contiennent des opérateurs de jointure sont éligibles pour trois algorithmes de jointures physiques, que sont les boucles imbriquées, les jointures hachées et les jointures de fusion. Si les estimations de cardinalité sont incorrectes pour les entrées de jointure, un algorithme de jointure inapproprié peut être sélectionné. au détriment des performances. L’algorithme de jointure non adapté continue d’être utilisé jusqu’à la recompilation du plan mis en cache.	Il existe un opérateur de jointure supplémentaire appelé jointure adaptive. Si les estimations de cardinalité sont incorrectes pour l’entrée de jointure de build externe, un algorithme de jointure inapproprié peut être sélectionné. Si cela se produit et que l’instruction est compatible avec une jointure adaptive, une boucle imbriquée est utilisée pour les entrées de jointure peu volumineuses, et une jointure hachée pour les autres, le tout dynamiquement et sans nécessiter de recompilation.
Les plans simples qui font référence à des index columnstore ne sont pas éligibles à l’exécution en mode batch.	Un plan simple qui référence des index columnstore sera supprimé en faveur d’un plan éligible pour l’exécution en mode batch.
L’opérateur UDX `sp_execute_external_script` peut uniquement être exécuté en mode ligne.	L’opérateur UDX `sp_execute_external_script` est éligible pour une exécution en mode batch.
Les Fonctions table (TVF, Table-Valued Function) à instructions multiples ne peuvent pas utiliser l’exécution entrelacée.	Pour les fonctions table à instructions multiples, l’exécution entrelacée améliore la qualité du plan.

Les correctifs qui se trouvaient sous l’indicateur de trace 4199 dans les versions de SQL Server antérieures à SQL Server 2017 sont maintenant activés par défaut avec le niveau de compatibilité 140. L’indicateur de trace 4199 est toujours applicable aux correctifs de l’optimiseur de requête qui ont été publiés après la publication de SQL Server 2017. Pour plus d’informations sur l’indicateur de trace 4199, consultez Indicateur de trace 4199.

Différences entre le niveau de compatibilité 120 et le niveau 130

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

Paramètre de niveau de compatibilité inférieur ou égal à 120	Paramètre de niveau de compatibilité égal à 130
Dans une instruction INSERT-SELECT, INSERT est monothread.	Dans une instruction INSERT-SELECT, INSERT est multithread ou peut présenter un plan parallèle.
Les requêtes d’une table à mémoire optimisée sont exécutées en monothread.	Les requêtes d’une table à mémoire optimisée peuvent désormais avoir des plans parallèles.
Comprend l’estimateur de cardinalité SQL 2014 CardinalityEstimationModelVersion="120"	Améliorations supplémentaires de l’estimation de cardinalité avec le modèle 130, visible à partir d’un plan de requête. CardinalityEstimationModelVersion="130"
Changements au niveau du mode batch et du mode ligne avec les index columnstore : Les tris sur une table avec un index columnstore s'effectuent en mode Ligne Les agrégats de fonction de fenêtrage fonctionnent en mode ligne (par exemple, `LAG` ou `LEAD`) Les requêtes exécutées sur des tables Columnstore avec plusieurs clauses distinctes sont exécutées en mode Ligne Les requêtes s’exécutant sous MAXDOP 1 ou avec un plan en série sont exécutées en mode ligne	Changements au niveau du mode batch et du mode ligne avec les index columnstore : Les tris sur une table avec un index columnstore s'effectuent désormais en mode Lot Les agrégats de fenêtrage fonctionnent désormais en mode batch (par exemple, `LAG` ou `LEAD`) Les requêtes exécutées sur des tables Columnstore avec plusieurs clauses distinctes sont exécutées en mode Lot Les requêtes exécutées sous MAXDOP 1 ou avec un plan en série sont exécutées en mode batch
Les statistiques peuvent être automatiquement mises à jour.	La logique qui met automatiquement à jour les statistiques est plus agressive sur les tables volumineuses. Dans la pratique, cela permet de réduire les problèmes de performances des requêtes lorsque des lignes qui viennent d’être insérées sont interrogées fréquemment, mais que les statistiques n’ont pas été mises à jour pour inclure ces valeurs.
La trace 2371 est désactivée par défaut dans SQL Server 2014 (12.x).	La trace 2371 est activée par défaut dans SQL Server 2016 (13.x). L’indicateur de trace 2371 demande au programme de mise à jour automatique des statistiques d’échantillonner un sous-ensemble de lignes plus petit mais plus raisonnable, dans une table qui comporte un grand nombre de lignes. L’une des améliorations est qu’il est désormais possible d’inclure dans l’échantillon plus de lignes que ce qui a été inséré récemment. Une autre amélioration est que vous pouvez laisser les requêtes s’exécuter pendant que le processus de mise à jour des statistiques s’exécute, plutôt que de bloquer les requêtes.
Pour le niveau 120, les statistiques sont échantillonnées par un processus monothread.	Pour le niveau 130, les statistiques sont échantillonnées par un processus multithread (parallèle).
Le nombre de clés étrangères entrantes est limité à 253.	Une table peut être référencée par un nombre maximal de 10 000 clés étrangères entrantes (ou types de références similaires). Pour connaître les restrictions associées, consultez Create Foreign Key Relationships.
Les algorithmes de hachage dépréciés MD2, MD4, MD5, SHA et SHA1 sont autorisés.	Seuls les algorithmes de hachage SHA2_256 et SHA2_512 sont autorisés.
	SQL Server 2016 (13.x) comprend des améliorations au niveau de certaines conversions de types de données et de certaines opérations (dont la plupart sont peu courantes). Pour plus d’informations, consultez Améliorations de SQL Server 2016 dans le traitement de certains types de données et des opérations peu courantes.
La fonction `STRING_SPLIT` n’est pas disponible.	La fonction `STRING_SPLIT` est disponible avec le niveau de compatibilité 130 ou supérieur. Si votre niveau de compatibilité de la base de données est inférieur à 130, SQL Server ne peut pas trouver ni exécuter la fonction `STRING_SPLIT`.

Les correctifs qui se trouvaient sous l’indicateur de trace 4199 dans les versions de SQL Server antérieures à SQL Server 2016 (13.x) sont maintenant activés par défaut avec le niveau de compatibilité 130. L’indicateur de trace 4199 est toujours applicable aux correctifs de l’optimiseur de requête qui ont été publiés après la publication de SQL Server 2016 (13.x). Pour utiliser l’ancien optimiseur de requête de SQL Database, vous devez sélectionner le niveau de compatibilité 110. Pour plus d’informations sur l’indicateur de trace 4199, consultez Indicateur de trace 4199.

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

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

Paramètre de niveau de compatibilité inférieur ou égal à 110	Paramètre de niveau de compatibilité égal à 120
L'ancien optimiseur de requête est utilisé.	SQL Server 2014 (12.x) comprend d’importantes améliorations au niveau du 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 la base de données sur 110 en raison de problèmes de performances, consultez les suggestions de la section Plans de requête de l’article SQL Server 2014 (12.x) Nouveautés dans le Moteur de base de données.
Dans les niveaux de compatibilité inférieurs à 120, le paramètre de langue est ignoré lors de la conversion d’une valeur de date en une valeur de chaîne. Ce comportement ne s’applique qu’au type date. Consultez l’exemple B dans la section Exemples .	Le paramètre de langue est pris en compte lors de la conversion d’une valeur de date en une valeur de chaîne.
Les références récursives à droite d’une clause `EXCEPT` créent une boucle infinie. L’exemple C de la section Exemples illustre ce comportement.	Les références récursives dans une `EXCEPT` clause génèrent une erreur en conformité avec la norme ANSI SQL.
L’expression de table commune récursive permet 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 change pas son état (activé ou désactivé).
La clause de table OUTPUT INTO ignore `IDENTITY_INSERT SETTING = OFF` et permet l’insertion de valeurs explicites.	Vous ne pouvez pas insérer de valeurs explicites dans une colonne d’identité d’une table quand `IDENTITY_INSERT` a la valeur OFF.
Lorsque la relation contenant-contenu de la 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` correspond au classement de la base de données et non à celui du serveur. Aucune erreur de conflit de classement n’est retournée.
Une instruction `SELECT INTO` crée toujours une opération d'insertion monothread.	Une instruction `SELECT INTO` 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.

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

Cette section décrit les nouveaux comportements introduits avec le niveau de compatibilité 110. Cette section s’applique également aux niveaux de compatibilité au-dessus de 110.

Paramètre de niveau de compatibilité inférieur ou égal à 100	Paramè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 Intégration du CLR - Nouveautés.	Les objets de base de données CLR sont exécutés avec la version 4 du CLR.
Les fonctions XQuery string-length et substring comptent chaque caractère de substitution comme deux caractères.	Les fonctions XQuery string-length et substring comptent chaque caractère de substitution comme un seul caractère.
`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 CTE. 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 (11.x), le matériel chiffré à l’aide de RC4 ou de RC4_128 peut être déchiffré avec n’importe quel niveau de compatibilité.	Le nouveau matériel ne peut pas être chiffré avec RC4 ni RC4_128. Utilisez à la place un algorithme plus récent, tel qu'un des algorithmes AES. Dans SQL Server 2012 (11.x), le matériel chiffré à l’aide de RC4 ou de RC4_128 peut être déchiffré avec n’importe quel niveau de compatibilité.
Le style par défaut des opérations `CAST` et `CONVERT` effectuées sur les types de données time et datetime2 est 121, sauf lorsque l’un des types est 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. L’exemple D de la section Exemples 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.	Lorsque le niveau de compatibilité est 110, le style par défaut pour les opérations `CAST` et `CONVERT` effectuées sur les types de données time et datetime2 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.
L’opérateur + (Addition) peut être appliqué à un opérande de type date, heure, datetime2 ou datetimeoffset si l’autre opérande a type datetime ou smalldatetime.	Essayer d’appliquer l’opérateur d’addition à un opérande de type date, time, datetime2 ou datetimeoffset et un opérande de type datetime ou smalldatetime provoque l’erreur 402.
Toutes les colonnes des tables distantes du type smalldatetime qui sont référencées dans une vue partitionnée sont mappées en tant que datetime. Les colonnes correspondantes dans les tables locales (dans la même position ordinale de 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 tant que smalldatetime. Les colonnes correspondantes dans les tables locales (dans la même position ordinale de 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 remplaçant le type de données dans la table distante par datetime ou en définissant le niveau de compatibilité de la base de données locale sur 100 (ou valeur inférieure).
La fonction `SOUNDEX` implémente les règles suivantes : 1) Les lettres H et W majuscules sont ignorées lors de la séparation de deux consonnes qui portent le même numéro dans le code `SOUNDEX`. 2) Si les deux premiers caractères de character_expression portent le même numéro dans le code `SOUNDEX`, ils sont tous les deux inclus. Sinon, si plusieurs consonnes côte à côte portent 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 un H ou un W majuscule sépare deux consonnes qui portent le même numéro dans le code `SOUNDEX`, la consonne située à droite est ignorée. 2) Si plusieurs consonnes côte à côte portent le même numéro dans le code `SOUNDEX`, toutes sont exclues à l’exception de la première. Les règles supplémentaires peuvent entraîner la différence entre les valeurs calculées par la `SOUNDEX` fonction et les valeurs calculées sous des niveaux de compatibilité antérieurs. Après la mise à niveau vers le niveau de compatibilité 110, vous devrez peut-être reconstruire les index, les segments de mémoire ou les contraintes CHECK qui utilisent la `SOUNDEX` fonction. Pour plus d’informations, consultez SOUNDEX.
`STRING_AGG` est disponible sans `<order_clause>`.	`STRING_AGG` est disponible avec une clause `<order_clause>` facultative. Pour plus d’informations, consultez STRING_AGG.

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

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

Paramètre de niveau de compatibilité égal à 90	Paramètre de niveau de compatibilité égal à 100	Possibilité d'impact
Le paramètre QUOTED_IDENTIFIER est toujours défini sur ON pour les fonctions table à états multiples lorsqu’elles sont créées, quel que soit le paramètre au niveau de la 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 de 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` ni dans les instructions `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
`CREATE FULLTEXT STOPLIST`, `ALTER FULLTEXT STOPLIST` et `DROP FULLTEXT STOPLIST` ne sont pas pris en charge. La liste de mots vides système est associée automatiquement aux nouveaux index de recherche en texte intégral.	`CREATE FULLTEXT STOPLIST`, `ALTER FULLTEXT STOPLIST` et `DROP FULLTEXT STOPLIST` sont pris 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 avec les niveaux de compatibilité 100 et 90.	Faible
L’utilisation de l’argument `<dml_table_source>` de l’instruction INSERT entraîne 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 `NOINDEX` est spécifié, `DBCC CHECKDB` ou `DBCC CHECKTABLE` effectue les vérifications de la cohérence physique et logique sur une table ou une vue indexée, ainsi que sur tous ses index non-cluster et XML. Les index spatiaux ne sont pas pris en charge.	Sauf si `NOINDEX` est spécifié, `DBCC CHECKDB` ou `DBCC CHECKTABLE` effectue les vérifications de la cohérence physique et logique sur une table, ainsi que sur tous ses index non-cluster. 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 `NOINDEX` est également spécifié, 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 d’abandon d’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 mettent fin au lot, et la transaction est restaurée.	Faible
CUBE et ROLLUP ne sont pas appliqués comme mots clés réservés.	`CUBE` et `ROLLUP` sont des mots clés réservés dans la clause GROUP BY.	Faible
La validation stricte est appliquée aux éléments du type XML anyType.	La validation souple (lax) est appliquée aux éléments du type anyType. 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 ni modifiés par des instructions de langage 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 de constante XML en type datetime SQL Server est marquée comme déterministe.	Une fonction définie par l’utilisateur qui convertit une valeur de chaîne de constante XML en type datetime SQL Server est marquée comme non déterministe.	Faible
Les types de liste et d’union XML ne sont pas totalement pris en charge.	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 inline.	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 des entités analysées externes (y compris l’entité de document) sont normalisés à l’entrée par la traduction en un caractère unique #xA de la séquence de deux caractères #xD #xA et de #xD non suivi de #xA. Les applications qui utilisent des attributs pour transporter des valeurs de chaîne contenant des caractères de fin de ligne ne reçoivent 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é. Il 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, à l’aide d’une affectation bidirectionnelle telle que `UPDATE T1 SET @v = column_name = <expression>`, peut produire des résultats inattendus car la valeur dynamique de la variable peut être utilisée dans d’autres clauses, telles que les clauses `WHERE` et `ON`, pendant l’exécution de l’instruction au lieu 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 de niveau `UNION` supérieur, mais retourne des résultats inattendus. Pour plus d’informations, consultez l’exemple E.	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. Recherchez une réécriture suggérée dans l’exemple E.	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, telles que `DATEPART` ne nécessitent pas de valeurs d’entrée de chaîne, soient des littéraux datetime valides. Par exemple, `SELECT DATEPART (year, '2007/05-30')` est compilé correctement.	Les intrinsèques datetime tels que `DATEPART` nécessitent 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
Les espaces de fin spécifiés dans le premier paramètre d’entrée de la fonction REPLACE sont supprimés lorsque le paramètre est de type char. Par exemple, dans l’instruction `SELECT '<' + REPLACE(CONVERT(char(6), 'ABC '), ' ', 'L') + '>'`, la valeur `'ABC '` est incorrectement évaluée en tant que `'ABC'`.	Les espaces de fin sont toujours conservés. Pour les applications qui s’appuient sur le comportement précédent de la fonction, utilisez la `RTRIM` fonction lors de la spécification du premier paramètre d’entrée pour la fonction. Par exemple, la syntaxe suivante reproduit le comportement de SQL Server 2005 : `SELECT '<' + REPLACE(RTRIM(CONVERT(char(6), 'ABC ')), ' ', 'L') + '>'`.	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
`130`	À déterminer.
`120`	Aucune.
`110`	`WITHIN GROUP`, , `TRY_CONVERTSEMANTICKEYPHRASETABLE`, , `SEMANTICSIMILARITYDETAILSTABLESEMANTICSIMILARITYTABLE`
`100`	`CUBE`, , `MERGEROLLUP`
`90`	`EXTERNAL`, , `PIVOTUNPIVOT`, , `REVERTTABLESAMPLE`

À 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 crochets ( [] ) ou entre guillemets ( "" ). Par exemple, pour effectuer la mise à niveau d’une application qui utilise l’identificateur EXTERNAL vers le niveau de compatibilité 90, vous pouvez remplacer l’identificateur par [EXTERNAL] ou "EXTERNAL".

Pour plus d’informations, consultez Mots clés réservés.

Autorisations

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

Exemples

R. Modification du niveau de compatibilité

L’exemple suivant modifie le niveau de compatibilité de l’exemple AdventureWorks2022 de base de données sur 150, la valeur par défaut pour SQL Server 2019 (15.x).

ALTER DATABASE AdventureWorks2022
SET COMPATIBILITY_LEVEL = 150;
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();
GO

B. Non-prise en compte de l’instruction SET LANGUAGE, sauf avec le niveau de compatibilité 120 ou un niveau supérieur

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

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

Résultat lorsque le niveau de compatibilité est inférieur à 120 : 12 May 2011.

Résultat lorsque le niveau de compatibilité est supérieur ou égal à 120 : 12 mei 2011.

C. Pour un paramètre de compatibilité de 110 ou inférieur, 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 cte
    UNION ALL
    (SELECT a FROM cte EXCEPT SELECT a FROM r)
)
SELECT a
FROM r;
GO

D. Différence entre les styles 0 et 121

Lorsque le niveau de compatibilité est inférieur à 110, le style par défaut des opérations CAST et CONVERT effectuées sur les types de données time et datetime2 est 121, sauf lorsque l’un des types est utilisé dans une expression de colonne calculée. Pour les colonnes calculées, le style par défaut est 0.

Lorsque le niveau de compatibilité est supérieur ou égal à 110, le style par défaut des opérations CAST et CONVERT effectuées sur les types de données time et datetime2 est toujours 121. Pour plus d’informations, consultez Différences entre les niveaux de compatibilité inférieurs et les niveaux 100 et 110.

Pour plus d’informations sur les styles de date et d’heure, consultez CAST et CONVERT.

DROP TABLE IF EXISTS t1;
GO

CREATE TABLE t1 (c1 time(7), c2 datetime2);
GO

INSERT t1 (c1,c2) VALUES (GETDATE(), GETDATE());
GO

SELECT CONVERT(nvarchar(16),c1,0) AS TimeStyle0
       ,CONVERT(nvarchar(16),c1,121)AS TimeStyle121
       ,CONVERT(nvarchar(32),c2,0) AS Datetime2Style0
       ,CONVERT(nvarchar(32),c2,121)AS Datetime2Style121
FROM t1;
GO

Les résultats sont les suivants :

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

E. Attribution de variable - opérateur UNION de niveau supérieur

Lorsque le paramètre de niveau de compatibilité de la base de données est égal à 90, l’attribution de variable est autorisée dans une instruction contenant un opérateur UNION de niveau supérieur, mais retourne 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 AdventureWorks2022
SET compatibility_level = 110;
GO
USE AdventureWorks2022;
GO
DECLARE @v int;
SELECT @v = BusinessEntityID FROM HumanResources.Employee
UNION ALL
SELECT @v = BusinessEntityID FROM HumanResources.EmployeeAddress;
SELECT @v;

Lorsque le paramètre de niveau de compatibilité de la base de données est supérieur ou égal à 100, 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;

Partager via

Niveau de compatibilité ALTER DATABASE (Transact-SQL)

Syntaxe

Arguments

database_name

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

Meilleures pratiques de mise à niveau du niveau de compatibilité de la base de données

Notes

Remarques pour Azure SQL

Rechercher le niveau de compatibilité actuel

Niveaux de compatibilité et mises à niveau du Moteur de base de données

Niveaux de compatibilité et procédures stockées

Utilisation du niveau de compatibilité pour la compatibilité descendante

Comparaison entre les niveaux de compatibilité

Différences entre le niveau de compatibilité 150 et le niveau 160

Différences entre le niveau de compatibilité 140 et le niveau 150

Différences entre le niveau de compatibilité 130 et le niveau 140

Différences entre le niveau de compatibilité 120 et le niveau 130

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

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

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

Mots clés réservés

Autorisations

Exemples

R. Modification du niveau de compatibilité

B. Non-prise en compte de l’instruction SET LANGUAGE, sauf avec le niveau de compatibilité 120 ou un niveau supérieur

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

D. Différence entre les styles 0 et 121

E. Attribution de variable - opérateur UNION de niveau supérieur

Commentaires

Ressources supplémentaires

Partager via

Niveau de compatibilité ALTER DATABASE (Transact-SQL)

Syntaxe

Arguments

database_name

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

Meilleures pratiques de mise à niveau du niveau de compatibilité de la base de données

Notes

Remarques pour Azure SQL

Rechercher le niveau de compatibilité actuel

Niveaux de compatibilité et mises à niveau du Moteur de base de données

Niveaux de compatibilité et procédures stockées

Utilisation du niveau de compatibilité pour la compatibilité descendante

Comparaison entre les niveaux de compatibilité

Différences entre le niveau de compatibilité 150 et le niveau 160

Différences entre le niveau de compatibilité 140 et le niveau 150

Différences entre le niveau de compatibilité 130 et le niveau 140

Différences entre le niveau de compatibilité 120 et le niveau 130

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

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

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

Mots clés réservés

Autorisations

Exemples

R. Modification du niveau de compatibilité

B. Non-prise en compte de l’instruction SET LANGUAGE, sauf avec le niveau de compatibilité 120 ou un niveau supérieur

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

D. Différence entre les styles 0 et 121

E. Attribution de variable - opérateur UNION de niveau supérieur

Contenu connexe

Commentaires

Ressources supplémentaires