Nivel de compatibilidad de ALTER DATABASE (Transact-SQL)

Artículo
01/18/2024

Se aplica a:SQL Server Azure SQL Database Azure SQL Managed Instance

Establece Transact-SQL y los comportamientos del procesamiento de consultas para que sean compatibles con la versión especificada del motor de SQL. Para más información sobre otras opciones de ALTER DATABASE, consulte ALTER DATABASE.

Para más información sobre las convenciones de sintaxis, vea Convenciones de sintaxis de Transact-SQL.

Sintaxis

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

Nota:

Para ver la sintaxis de Transact-SQL para SQL Server 2014 (12.x) y versiones anteriores, consulte Versiones anteriores de la documentación.

Argumentos

database_name

Nombre de la base de datos que se va a modificar.

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

La versión de SQL Server con la que se va a hacer compatible la base de datos. Se pueden configurar los siguientes valores de nivel de compatibilidad (no todas las versiones admiten todo el nivel de compatibilidad mencionado anteriormente):

Producto	Versión del motor de base de datos	Designación del nivel de compatibilidad predeterminado	Valores de nivel de compatibilidad admitidos
Azure SQL Database	16	150	160, 150, 140, 130, 120, 110, 100
Instancia administrada de Azure SQL	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

Importante

Los números de versión del motor de base de datos para SQL Server y Azure SQL Database no son comparables entre sí y, en su lugar, son números de compilación internos para estos productos independientes. El motor de base de datos de Azure SQL Database se basa en el mismo código base que el de SQL Server. Lo más importante es que el motor de base de datos de Azure SQL Database siempre tiene los bits más recientes del motor de base de datos SQL. La versión 12 de Azure SQL Database es más reciente que la versión 15 de SQL Server.

Prácticas recomendadas para actualizar el nivel de compatibilidad de la base de datos

Si desea conocer el flujo de trabajo recomendado para actualizar el nivel de compatibilidad, consulte Mantener la estabilidad del rendimiento al actualizar a una versión más reciente de SQL Server. Además, para una experiencia asistida con la actualización del nivel de compatibilidad de base de datos, consulte Actualización de bases de datos mediante el Asistente para la optimización de consultas.

Observaciones

En todas las instalaciones de SQL Server, el nivel de compatibilidad predeterminado está asociado a la versión del Motor de base de datos. Las nuevas bases de datos se establecen en este nivel a menos que la base de datos model tenga un nivel de compatibilidad inferior. En el caso de las bases de datos adjuntadas o restauradas desde una versión anterior de SQL Server, dicha base de datos mantiene su nivel de compatibilidad si es al menos la versión mínima permitida para esa instancia de SQL Server. Mover una base de datos con un nivel de compatibilidad inferior al nivel permitido mediante el Motor de base de datos hace que la base de datos se establezca automáticamente en el nivel de compatibilidad más bajo permitido. Esto se aplica a las bases de datos del usuario y del sistema.

Se esperan los siguientes comportamientos para SQL Server 2017 (14.x) cuando se adjunta o restaura una base de datos y después de una actualización local:

Si el nivel de compatibilidad de una base de datos de usuario era 100 o superior antes de la actualización, permanece igual después de la misma.
Si el nivel de compatibilidad de una base de datos de usuario era 90 antes de la actualización, en la base de datos actualizada el nivel de compatibilidad se establece en 100, que es el nivel de compatibilidad mínimo admitido en SQL Server 2017 (14.x).
Los niveles de compatibilidad de las bases de datos tempdb, model, msdb y Resource se establecen en el nivel de compatibilidad predeterminado de una versión del Motor de base de datos determinada.
La base de datos del sistema master conserva el nivel de compatibilidad que tenía antes de la actualización. Esto no afectará al comportamiento de la base de datos de usuario.

Para las bases de datos que ya existían y que se ejecutan con niveles de compatibilidad inferiores, siempre y cuando la aplicación no necesite usar las mejoras que solo están disponibles en un nivel de compatibilidad de base de datos superior, es un enfoque válido para mantener el nivel de compatibilidad de la base de datos anterior. Para los nuevos trabajos de desarrollo, o en el caso de que una aplicación existente requiera el uso de características nuevas, como el Procesamiento de consultas inteligentes, así como Transact-SQL nuevo, plantéese actualizar el nivel de compatibilidad de la base de datos a la última versión disponible. Para obtener más información, consulte Actualizaciones del motor de base de datos y niveles de compatibilidad.

Nota

Si no hay ningún objeto de usuario ni dependencia, generalmente es seguro actualizar al nivel de compatibilidad predeterminado. Para más información, consulte Recomendaciones: base de datos maestra.

Use ALTER DATABASE para cambiar el nivel de compatibilidad de la base de datos. El nuevo nivel de compatibilidad de una base de datos se hace efectivo cuando se emite un comando USE <database> o se procesa un nuevo inicio de sesión con esa base de datos como contexto de base de datos predeterminada. Para ver el nivel de compatibilidad actual de una base de datos, consulte la columna compatibility_level en la vista de catálogo sys.databases.

Una base de datos de distribución creada en una versión anterior de SQL Server y que se actualiza a SQL Server 2016 (13.x) RTM o Service Pack 1 tiene el nivel de compatibilidad 90, que no es compatible con otras bases de datos. Esto no afecta a la funcionalidad de la replicación. Si se actualiza a un service pack o a una versión posterior de SQL Server, el nivel de compatibilidad de la base de datos de distribución aumentará para coincidir con el de la base de datos master.

Para usar el nivel de compatibilidad de la base de datos 120 o superior para su base de datos global, pero poder optar al modelo de estimación de cardinalidad de SQL Server 2012 (11.x), que se asigna al nivel de compatibilidad 110 de la base de datos, vea ALTER DATABASE SCOPED CONFIGURATION y, en concreto, su palabra clave LEGACY_CARDINALITY_ESTIMATION = ON.

Para averiguar el nivel de compatibilidad actual, consulte la columna compatibility_level de sys.databases.

SELECT name, compatibility_level FROM sys.databases;

Comentarios para Azure SQL

A partir de noviembre de 2022, el nivel de compatibilidad predeterminado para las bases de datos recién creadas en Azure SQL Database y Azure SQL Managed Instance. Microsoft no actualiza el nivel de compatibilidad de las bases de datos existentes. Queda a la elección de los clientes. Microsoft recomienda encarecidamente que los clientes planeen la actualización al último nivel de compatibilidad con el fin de utilizar las últimas mejoras de optimización de consulta.

Para obtener más información sobre cómo valorar las diferencias de rendimiento de las consultas más importantes entre dos niveles de compatibilidad diferentes de Azure SQL Database, vea la mejora en el rendimiento de las consultas con el nivel de compatibilidad 130 de Azure SQL Database. En este artículo se hace referencia al nivel de compatibilidad 130 y a SQL Server, aunque se aplica la misma metodología a las actualizaciones al nivel de compatibilidad 140 o superior en SQL Server y Azure SQL Database.

Para determinar la versión del Motor de base de datos al que está conectado, ejecute la consulta siguiente.

SELECT SERVERPROPERTY('ProductVersion');

No todas las características que varían según el nivel de compatibilidad se admiten en Azure SQL Database.

Actualizaciones del motor de base de datos y niveles de compatibilidad

El nivel de compatibilidad de la base de datos es una valiosa herramienta que sirve para ayudar a la modernización de las bases de datos, ya que permite actualizar el Motor de base de datos de SQL Server mientras se conserva el estado funcional para las aplicaciones conectadas al mantener el mismo nivel de compatibilidad de la base de datos previo a la actualización. Esto significa que es posible actualizar una versión anterior de SQL Server (como SQL Server 2008 [10.0.x]) a SQL Server o Azure SQL Database (incluido Azure SQL Managed Instance) sin cambios en la aplicación (salvo en lo que respecta a la conectividad de la base de datos). Para obtener más información, vea Certificación de compatibilidad.

Siempre y cuando la aplicación no necesite usar las mejoras que solo están disponibles en un nivel de compatibilidad de base de datos superior, es un enfoque válido para actualizar el Motor de base de datos de SQL Server y mantener el nivel de compatibilidad de la base de datos anterior. Para obtener más información sobre cómo usar el nivel de compatibilidad para la compatibilidad con versiones anteriores, vea Certificación de compatibilidad.

Niveles de compatibilidad y procedimientos almacenados

Cuando se ejecuta un procedimiento almacenado, se usa el nivel de compatibilidad actual de la base de datos en la que se define. Cuando se cambia el nivel de compatibilidad de una base de datos, todos sus procedimientos almacenados se vuelven a compilar de forma automática según sea necesario.

Uso del nivel de compatibilidad para la compatibilidad con versiones anteriores

La configuración del nivel de compatibilidad de la base de datos proporciona compatibilidad con versiones anteriores de SQL Server en lo que se refiere a Transact-SQL y los comportamientos de optimización de consulta solo para la base de datos especificada, no para todo el servidor.

A partir del modo de compatibilidad 130, todo plan de consulta que afecte a las correcciones y a las características se ha agregado únicamente al nuevo nivel de compatibilidad de forma intencionada. La finalidad de esto ha sido reducir el riesgo durante las actualizaciones que surgen de la degradación del rendimiento debido a los cambios en el plan de consulta potencialmente introducidos por los nuevos comportamientos de optimización de consulta.

Desde la perspectiva de las aplicaciones, use el nivel de compatibilidad inferior como ruta más segura para la migración para solucionar diferencias de comportamiento entre las versiones que se controlan con el valor de nivel de compatibilidad correspondiente. El objetivo debería seguir siendo actualizar al nivel de compatibilidad más reciente en algún momento para heredar algunas de las nuevas características, como el procesamiento inteligente de consultas, pero hacerlo de un modo controlado.

Para obtener más información, así como el flujo de trabajo recomendado para actualizar el nivel de compatibilidad de la base de datos, vea Prácticas recomendadas para actualizar el nivel de compatibilidad de la base de datos.

La funcionalidad descontinuada incluida en una determinada versión de SQL Serverno está protegida por el nivel de compatibilidad. Esto hace referencia a una funcionalidad que se quitó del Motor de base de datos de SQL Server. Por ejemplo, la sugerencia FASTFIRSTROW está descontinuada en SQL Server 2012 (11.x) y se ha reemplazado por la sugerencia OPTION (FAST n ). Establecer el nivel de compatibilidad de la base de datos en 110 no restaurará la sugerencia descontinuada. Para más información sobre las funcionalidades no incluidas, consulte Funcionalidad del motor de base de datos no incluida en SQL Server.
Los cambios importantes incluidos en una determinada versión de SQL Serverpueden no estar protegidos por el nivel de compatibilidad. Esto hace referencia a cambios de comportamiento entre las versiones del Motor de base de datos de SQL Server. El comportamiento de Transact-SQL suele estar protegido por el nivel de compatibilidad. En cambio, los objetos del sistema eliminados o modificados no están protegidos por el nivel de compatibilidad.

Un ejemplo de cambio importante protegido por nivel de compatibilidad es una conversión implícita de tipos de datos datetime a datetime2 . En el nivel de compatibilidad de base de datos 130, esto muestra una mayor precisión al reflejar las fracciones de milisegundos, lo que se traduce en diferentes valores convertidos. Para restaurar el comportamiento de conversión anterior, establezca el nivel de compatibilidad de base de datos en 120 o en uno inferior.

Estos son algunos ejemplos de cambios importantes no protegidos por el nivel de compatibilidad:
- Nombres de columna modificados en objetos del sistema. En SQL Server 2012 (11.x), el nombre de la columna single_pages_kb de sys.dm_os_sys_info se ha cambiado a pages_kb. Independientemente del nivel de compatibilidad, la consulta SELECT single_pages_kb FROM sys.dm_os_sys_info generará el error 207 (Nombre de columna no válido).
- Objetos del sistema quitados. En SQL Server 2012 (11.x), la columna sp_dboption se ha quitado. Independientemente del nivel de compatibilidad, la instrucción EXEC sp_dboption 'AdventureWorks2022', 'autoshrink', 'FALSE'; producirá el error 2812 (Couldn't find stored procedure 'sp_dboption').
Para más información sobre los cambios importantes, consulte Cambios sustanciales en las características del motor de base de datos de SQL Server 2019, Cambios substanciales en las características del motor de base de datos de SQL Server 2017, Cambios sustanciales en las características del motor de base de datos de SQL Server 2016 y Cambios sustanciales en las características del motor de base de datos de SQL Server 2014.

Diferencias entre los niveles de compatibilidad

En todas las instalaciones de SQL Server, el nivel de compatibilidad predeterminado está asociado a la versión del Motor de base de datos, tal como se muestra en esta tabla. En los nuevos trabajos de desarrollo, planee siempre la certificación de aplicaciones en el nivel de compatibilidad de la base de datos más reciente.

La nueva sintaxis de Transact-SQL no se valida mediante el nivel de compatibilidad de la base de datos, excepto cuando puede interrumpir las aplicaciones existentes creando un conflicto con el código de Transact-SQL de usuario. Estas excepciones se documentan en las siguientes secciones de este artículo en las que se describen las diferencias entre los niveles de compatibilidad específicos.

El nivel de compatibilidad de la base de datos también proporciona compatibilidad con versiones anteriores de SQL Server, dado que las bases de datos asociadas o restauradas desde cualquier versión anterior de SQL Server conservan su nivel de compatibilidad existente (si es igual o mayor que el nivel de compatibilidad mínimo permitido). Esto se analizó en la sección Uso del nivel de compatibilidad para la compatibilidad con versiones anteriores de este artículo.

A partir del nivel de compatibilidad de la base de datos 130, las nuevas correcciones y características que afectan a los planes de consulta se han agregado solo al nivel de compatibilidad más reciente disponible, también denominado nivel de compatibilidad predeterminado. La finalidad de esto ha sido reducir el riesgo durante las actualizaciones que surgen de la degradación del rendimiento debido a los cambios en el plan de consulta potencialmente introducidos por los nuevos comportamientos de optimización de consulta.

Los cambios fundamentales que afectan al plan y que solo se agregan al nivel de compatibilidad predeterminado de una nueva versión del Motor de base de datos son:

Las correcciones del optimizador de consultas publicadas para las versiones anteriores de SQL Server en la marca de seguimiento 4199 se habilitan automáticamente en el nivel de compatibilidad predeterminado de una versión de SQL Server más reciente.

Se aplica a: SQL Server (a partir de la versión SQL Server 2016 (13.x)), Azure SQL Database.

Por ejemplo, cuando se lanzó SQL Server 2016 (13.x), todas las correcciones del optimizador de consultas publicadas para las versiones anteriores de SQL Server (y los niveles de compatibilidad respectivos de 100 a 120) se habilitaron automáticamente para las bases de datos que usan el nivel de compatibilidad predeterminado (130) de SQL Server 2016 (13.x). Solo es necesario habilitar explícitamente las correcciones del optimizador de consultas posteriores a RTM.

Para habilitar las correcciones del optimizador de consultas, se pueden usar los métodos siguientes:

En el nivel de servidor, con marca de seguimiento 4199.
En el nivel de base de datos, con la opción QUERY_OPTIMIZER_HOTFIXES en ALTER DATABASE SCOPED CONFIGURATION (Transact-SQL).
En el nivel de consulta, mediante la modificación de la consulta con la sugerencia de consultaUSE HINT 'ENABLE_QUERY_OPTIMIZER_HOTFIXES'.
En el nivel de consulta, con USE HINT 'ENABLE_QUERY_OPTIMIZER_HOTFIXES' sin cambios de código, mediante la característica Sugerencia del Almacén de consultas sugerencia (versión preliminar).

Más adelante, cuando se lanzó SQL Server 2017 (14.x), todas las correcciones del optimizador de consultas publicadas después de SQL Server 2016 (13.x) RTM se habilitaron automáticamente para las bases de datos con el nivel de compatibilidad predeterminado (140) de SQL Server 2017 (14.x). Se trata de un comportamiento acumulativo que incluye también todas las correcciones de versiones anteriores. De nuevo, solo es necesario habilitar explícitamente las correcciones del optimizador de consultas posteriores a RTM.

En la tabla siguiente se resume este comportamiento:

Versión del motor de base de datos (DE)	Nivel de compatibilidad de la base de datos	TF 4199	Cambios del optimizador de consultas con respecto a todos los niveles de compatibilidad de la base de datos anteriores	Cambios del optimizador de consultas para la versión del motor de base de datos posterior a RTM
13 (SQL Server 2016 (13.x))	De 100 a 120 130	Off Por Off Por	Deshabilitada habilitado Enabled habilitado	Disabled habilitado Disabled habilitado
14 (SQL Server 2017 (14.x))	De 100 a 120 130 140	Off Por Off Por Off Por	Deshabilitada habilitado Enabled habilitado Enabled habilitado	Disabled habilitado Disabled habilitado Disabled habilitado
15 (SQL Server 2019 (15.x)) y 12 (Azure SQL Database)	De 100 a 120 De 130 a 140 150	Off Por Off Por Off Por	Deshabilitada habilitado Enabled habilitado Enabled habilitado	Disabled habilitado Disabled habilitado Disabled habilitado
16 (SQL Server 2022 (16.x)) y 12 (Azure SQL Database)	De 100 a 120 De 130 a 150 160	Off Por Off Por Off Por	Deshabilitada habilitado Enabled habilitado Enabled habilitado	Disabled habilitado Disabled habilitado Disabled habilitado

Las correcciones del optimizador de consultas que se ocupan de resultados incorrectos o de errores de infracción de acceso no están protegidas por la marca de seguimiento 4199. Dichas correcciones no se consideran opcionales.

Los cambios en el estimador de cardinalidad publicados en SQL Server y Azure SQL Database solo están habilitados en el nivel de compatibilidad predeterminado de una versión nueva de Motor de base de datos , pero no en los niveles de compatibilidad anteriores.

Por ejemplo, cuando se publicó SQL Server 2016 (13.x), los cambios en el proceso de estimación de la cardinalidad solo estaban disponibles para las bases de datos que tenían el nivel de compatibilidad predeterminado (130) de SQL Server 2016 (13.x). Los niveles de compatibilidad anteriores retuvieron el comportamiento de estimación de cardinalidad que estaba disponible antes de SQL Server 2016 (13.x).

Posteriormente, cuando se publicó SQL Server 2017 (14.x), los cambios más recientes en el proceso de estimación de la cardinalidad solo estaban disponibles para las bases de datos que tenían el nivel de compatibilidad predeterminado (140) de SQL Server 2017 (14.x). El nivel de compatibilidad 130 de la base de datos conserva el comportamiento de estimación de cardinalidad de SQL Server 2016 (13.x).

En la tabla siguiente se resume este comportamiento:

Versión del motor de base de datos	Nivel de compatibilidad de la base de datos	Nuevos cambios de versión de CE
13 (SQL Server 2016 (13.x))	< 130 130	Disabled habilitado
14 (SQL Server 2017 (14.x))¹	< 140 140	Disabled habilitado
15 (SQL Server 2019 (15.x))¹	< 150 150	Disabled habilitado
16 (SQL Server 2022 (16.x))¹	< 160 160	Disabled habilitado

¹ También es aplicable a Azure SQL Database.

En las secciones siguientes de este artículo se muestran otras diferencias entre niveles de compatibilidad específicos.

Diferencias entre los niveles de compatibilidad 150 y 160

En esta sección, se describen comportamientos nuevos incluidos con el nivel de compatibilidad 160.

Nivel de compatibilidad 150 o inferior	Nivel de compatibilidad 160
Las consultas con parámetros tienen un plan de consulta único basado en los parámetros usados en la primera ejecución. Solo se almacena en caché un plan de consulta, el que se usa para todos los valores de parámetro. Esto puede provocar que un plan de consulta sea ineficaz para algunos valores del parámetro, también conocido como plan con distinción de parámetros.	Las consultas con parámetros pueden tener varios planes de consulta almacenados en caché para diferentes categorías de selectividad de un parámetro. La optimización del plan con distinción de parámetros está habilitada de manera predeterminada en el nivel de compatibilidad 160. Para más información, consulte Optimización de PSP.
La estimación de cardinalidad usa solo un conjunto predeterminado de suposiciones de modelo sobre los patrones de uso y distribución de datos subyacentes para todas las bases de datos y consultas. La única manera de cambiar o ajustar cualquiera de esas suposiciones es cuando el usuario lleva a cabo un proceso manual para indicar explícitamente qué suposiciones de modelo se deben usar, mediante el uso de sugerencias de consulta. No se puede realizar ningún ajuste interno en este modelo predeterminado después de generar un plan de consulta.	La estimación de cardinalidad comienza con el conjunto predeterminado de suposiciones de modelo sobre los patrones de uso y distribución de datos subyacentes, pero después de algunas ejecuciones de una consulta determinada, el Motor de base de datos aprende qué conjuntos de suposiciones de modelo diferentes pueden generar estimaciones más precisas y, por tanto, ajusta las suposiciones en uso para que coincidan mejor con el conjunto de datos que se consulta. Los comentarios sobre la estimación de cardinalidad están habilitados de manera predeterminada en el nivel de compatibilidad 160. Para más información, consulte Comentarios de estimación de cardinalidad.
El Motor de base de datos no intenta determinar automáticamente el grado óptimo de paralelismo. Para información sobre cómo controlar manualmente el grado máximo de paralelismo (MAXDOP) en los niveles de instancia, base de datos, consulta o carga de trabajo, consulte Establecer la opción de configuración del servidor Grado máximo de paralelismo.	La característica Comentarios de grado de paralelismo (DOP) mejora el rendimiento de las consultas mediante la identificación de ineficiencias de paralelismo para las consultas repetidas, en función del tiempo transcurrido y las esperas. Si el uso del paralelismo se considera ineficaz, los Comentarios de grado de paralelismo reducen el grado de paralelismo de la siguiente ejecución de la consulta, esté como esté configurado el grado de paralelismo, y comprueba si esto ayuda. La característica Comentarios de grado de paralelismo no está habilitada de manera predeterminada. Para habilitarla, habilite la configuración con ámbito de base de datos `DOP_FEEDBACK` en una base de datos. Para más información, consulte Comentarios de grado de paralelismo.

Diferencias entre los niveles de compatibilidad 140 y 150

En esta sección se describen los nuevos comportamientos incluidos en el nivel de compatibilidad 150.

Nivel de compatibilidad 140 o inferior	Nivel de compatibilidad 150
Es posible que el almacenamiento de datos relacional y las cargas de trabajo analíticas no puedan usar índices de almacén de columnas debido a la sobrecarga olTP, la falta de soporte técnico del proveedor u otras limitaciones. Sin índices de almacén de columnas, estas cargas de trabajo no pueden beneficiarse del modo de ejecución por lotes.	El modo de ejecución por lotes ahora está disponible para las cargas de trabajo de análisis sin necesidad de índices de almacén de columnas. Para más información, consulte el modo por lotes en el almacén de filas.
Las consultas en modo de fila que solicitan tamaños de concesión de memoria insuficientes que dan lugar a desbordamientos en el disco podrían seguir teniendo problemas en ejecuciones consecutivas.	Las consultas en modo de fila que solicitan tamaños de concesión de memoria insuficientes que dan lugar a desbordamientos en disco podrían haber mejorado el rendimiento en ejecuciones consecutivas. Para más información, consulte los comentarios de concesión de memoria en modo de fila.
Las consultas en modo de fila que solicitan un tamaño excesivo de concesión de memoria que da lugar a problemas de simultaneidad pueden seguir teniendo problemas en ejecuciones consecutivas.	Las consultas en modo de fila que solicitan un tamaño excesivo de concesión de memoria que da lugar a problemas de simultaneidad podrían haber mejorado la simultaneidad en ejecuciones consecutivas. Para más información, consulte los comentarios de concesión de memoria en modo de fila.
Las consultas que hacen referencia a UDF escalares de T-SQL usarán invocación iterativa, carecerán de gestión de costos y forzarán la ejecución en serie.	Los UDF escalares de T-SQL se transforman en expresiones relacionales equivalentes que se "insertan" en la consulta que realiza la llamada, lo que a menudo supone una notable mejora del rendimiento. Para más información, consulte Inserción de UDF escalar de T-SQL.
Las variables de tabla usan una estimación fija para el cálculo de la cardinalidad. Si el número real de filas es mucho mayor que el valor estimado, el rendimiento de las operaciones de bajada puede verse afectado.	Los nuevos planes usarán la cardinalidad real de la variable de tabla detectada en la primera compilación en lugar de una estimación fija. Para más información, consulte Compilación diferida de variables de tabla.

Para más información sobre las características de procesamiento de consultas habilitadas en el nivel de compatibilidad 150 de la base de datos, consulte Novedades de SQL Server 2019 y Procesamiento de consultas inteligente en bases de datos SQL.

Diferencias entre los niveles de compatibilidad 130 y 140

En esta sección se describen los nuevos comportamientos incluidos en el nivel de compatibilidad 140.

Nivel de compatibilidad 130 o inferior	Nivel de compatibilidad 140
En las estimaciones de cardinalidad de las instrucciones que hacen referencia a funciones con valores de tabla de múltiples instrucciones se usa una estimación de fila fija.	En las estimaciones de cardinalidad de las instrucciones que hacen referencia a funciones con valores de tabla de múltiples instrucciones se usará la cardinalidad real de la salida de la función. Esto es posible gracias a la ejecución intercalada de funciones con valores de tabla de múltiples instrucciones.
Las consultas en modo por lotes que solicitan tamaños de concesión de memoria insuficientes que producen desbordamientos en el disco podrían seguir teniendo problemas en ejecuciones consecutivas.	Las consultas en modo por lotes que solicitan tamaños de concesión de memoria insuficientes que producen desbordamientos en el disco podrían haber mejorado el rendimiento en ejecuciones consecutivas. Esto es posible a través de los comentarios de concesión de memoria del modo por lotes, que actualizarán el tamaño de concesión de memoria de un plan en caché si se han producido desbordamientos en el caso de los operadores de modo por lotes.
Las consultas en modo por lotes que solicitan un tamaño excesivo de concesión de memoria que da lugar a problemas de simultaneidad pueden seguir teniendo problemas en ejecuciones consecutivas.	Las consultas en modo por lotes que solicitan un tamaño excesivo de concesión de memoria que da lugar a problemas de simultaneidad podrían haber mejorado la simultaneidad en ejecuciones consecutivas. Esto es posible a través de los comentarios de concesión de memoria del modo por lotes, que actualizarán el tamaño de concesión de memoria de un plan en caché si se ha solicitado inicialmente una cantidad excesiva.
Las consultas de modo por lotes que contienen operadores de combinación son aptas para tres algoritmos de combinación físicos, a saber, bucle anidado, combinación hash y combinación de mezcla. Si las estimaciones de cardinalidad son incorrectas para las entradas de combinación, es posible que se seleccione un algoritmo de combinación inadecuado. Si esto sucede, el rendimiento se verá afectado y el algoritmo de combinación incorrecto seguirá en uso hasta que el plan en caché se vuelva a compilar.	Hay otro operador de combinación denominado combinación adaptable. Si las estimaciones de cardinalidad son incorrectas para la entrada de combinación de compilación externa, podría seleccionarse un algoritmo de combinación inadecuado. Si esto sucede y la instrucción es apta para una combinación adaptable, se usará dinámicamente un bucle anidado en las entradas de combinación más pequeñas y una combinación hash en las entradas de combinación mayores, sin necesidad realizar ninguna recompilación.
Los planes triviales que hacen referencia a los índices de almacén de columnas no son válidos para ejecutarse en el modo por lotes.	Un plan trivial que hace referencia a índices de almacén de columnas se descartarán en favor de un plan que sea apto para ejecutarse en el modo por lotes.
El operador UDX `sp_execute_external_script` solo se puede ejecutar en el modo de fila.	El operador UDX `sp_execute_external_script` se puede usar en la ejecución del modo por lotes.
Las funciones con valores de tabla (TVF) de varias instrucciones carecen de ejecución intercalada.	La ejecución intercalada es posible en las funciones con valores de tabla de múltiples instrucciones para mejorar la calidad del plan.

Las correcciones incluidas en la marca de seguimiento 4199 en versiones de SQL Server anteriores a SQL Server 2017 ahora están habilitadas de forma predeterminada en el modo de compatibilidad 140. La marca de seguimiento 4199 sigue siendo aplicable a las nuevas correcciones del optimizador de consultas que se publiquen después de SQL Server 2017. Para más información sobre la marca de seguimiento 4199, vea la marca de seguimiento 4199.

Diferencias entre los niveles de compatibilidad 120 y 130

En esta sección se describen los nuevos comportamientos incluidos en el nivel de compatibilidad 130.

Nivel de compatibilidad 120 o inferior	Nivel de compatibilidad 130
La instrucción INSERT en una instrucción INSERT-SELECT es de subproceso único.	La instrucción INSERT en una instrucción INSERT-SELECT es multiproceso o puede tener un plan paralelo.
Las consultas en una tabla optimizada para memoria ejecutan un único subproceso.	Ahora, las consultas en una tabla optimizada para memoria pueden tener planes paralelos.
Incluyó el programa de estimación de cardinalidad de SQL 2014 CardinalityEstimationModelVersion="120" .	Más mejoras en la estimación de cardinalidad con el modelo de estimación de cardinalidad 130, que es visible desde una consulta. CardinalityEstimationModelVersion="130"
Cambios del modo por lotes frente al modo de fila con índices de almacén de columnas: Las ordenaciones en una tabla con índice de almacén de columnas se producen en el modo de fila. Los agregados de función basados en ventanas funcionan en el modo de fila, como `LAG` o `LEAD`. Las consultas en tablas de almacén de columnas con varias cláusulas Distinct funcionaban en el modo de fila. Las consultas que se ejecutan con Maxdop1 o un plan de consulta en serie se ejecutaban en el modo de fila.	Cambios del modo por lotes frente al modo de fila con índices de almacén de columnas: Ahora, las ordenaciones en una tabla con índice de almacén de columnas se producen en el modo por lotes. Ahora, los agregados basados en ventanas funcionan en el modo por lotes, como `LAG` o `LEAD`. Las consultas en tablas de almacén de columnas con varias cláusulas Distinct funcionaban en el modo por lotes. Las consultas que se ejecutan con MAXDOP 1 o con un plan de consulta en serie se ejecutan en el modo por lotes.
Las estadísticas se pueden actualizar automáticamente.	La lógica que actualiza las estadísticas automáticamente es más agresiva en tablas grandes. En la práctica, esto debería reducir los casos en los que los clientes advierten problemas de rendimiento en las consultas donde las filas recién insertadas se consultan con frecuencia, pero las estadísticas no se habían actualizado para incluir esos valores.
La marca de seguimiento 2371 está desactivada de forma predeterminada en SQL Server 2014 (12.x).	La marca de seguimiento 2371 está activada de forma predeterminada en SQL Server 2016 (13.x). La marca de seguimiento 2371 indica al actualizador automático de estadísticas que muestree un subconjunto de filas más pequeño, pero más práctico, en una tabla que tiene un gran número de filas. Una mejora consiste en incluir en el ejemplo más filas que se hayan insertado hace poco. Otra mejora es permitir que las consultas se ejecuten mientras el proceso de actualización de estadísticas se ejecuta, en lugar de bloquearlas.
En el nivel 120, las estadísticas se muestrean a través de un proceso desubproceso único.	En el nivel 130, las estadísticas se muestrean a través de un proceso multiproceso (proceso en paralelo).
El límite está establecido en 253 claves externas entrantes.	Hasta 10 000 claves externas entrantes (o referencias similares) pueden hacer referencia a una determinada tabla. Para ver las restricciones, vea Create Foreign Key Relationships.
Se permiten los algoritmos hash en desuso MD2, MD4, MD5, SHA y SHA1.	Solo se permiten los algoritmos hash SHA2_256 y SHA2_512.
	SQL Server 2016 (13.x) incluye mejoras en algunas operaciones (bastante infrecuentes) y conversiones de tipos de datos. Para más información, vea SQL Server 2016 improvements in handling some data types and uncommon operations (Mejoras de SQL Server 2016 en el tratamiento de algunos tipos de datos y operaciones infrecuentes).
La función `STRING_SPLIT` no está disponible.	La función `STRING_SPLIT` está disponible en el nivel de compatibilidad 130 o superior. Si el nivel de compatibilidad de la base de datos es inferior a 130, SQL Server no podrá encontrar ni ejecutar la función `STRING_SPLIT`.

Las correcciones incluidas en la marca de seguimiento 4199 en versiones de SQL Server anteriores a SQL Server 2016 (13.x) ahora están habilitadas de forma predeterminada en el modo de compatibilidad 130. La marca de seguimiento 4199 sigue siendo aplicable a las nuevas correcciones del optimizador de consultas que se publiquen después de SQL Server 2016 (13.x). Para usar el optimizador de consultas anterior en SQL Database, hay que seleccionar el nivel de compatibilidad 110. Para más información sobre la marca de seguimiento 4199, vea la marca de seguimiento 4199.

Diferencias entre los niveles de compatibilidad inferiores y el nivel 120

En esta sección se describen nuevos comportamientos incluidos con el nivel de compatibilidad 120.

Nivel de compatibilidad 110 o inferior	Nivel de compatibilidad 120
Se utiliza el optimizador de consultas más antiguo.	SQL Server 2014 (12.x) incluye mejoras sustanciales en el componente que crea y optimiza los planes de consulta. Esta nueva característica del optimizador de consultas depende del uso del nivel 120 de compatibilidad de base de datos. Para aprovecharse estas mejoras, las nuevas aplicaciones de base de datos deben desarrollarse con el nivel 120 de compatibilidad de base de datos. Las aplicaciones migradas de versiones anteriores de SQL Server deben probarse cuidadosamente para confirmar que el buen rendimiento se ha mantenido o se ha mejorado. Si el rendimiento se degrada, puede establecer la compatibilidad de base de datos en el nivel 110 o inferior para usar la anterior metodología del optimizador de consultas. El nivel de compatibilidad de la base de datos 120 usa un nuevo estimador de cardinalidad que está optimizado para cargas de trabajo modernas de almacenamiento de datos y OLTP. Antes de establecer el nivel de compatibilidad de la base de datos en 110 debido a problemas de rendimiento, vea las recomendaciones incluidas en la sección Planes de consulta del artículo Novedades del Motor de base de datos de SQL Server 2014 (12.x).
En niveles de compatibilidad inferiores a 120, la configuración de idioma se omite al convertir un valor date en un valor de cadena. Este comportamiento es específico exclusivamente del tipo date. Vea el ejemplo B en la sección Ejemplos .	La configuración de idioma no se ignora al convertir un valor date en un valor de cadena.
Las referencias recursivas en el lado derecho de una cláusula `EXCEPT` crean un bucle infinito. En el ejemplo C de la sección Ejemplos se muestra este comportamiento.	Las referencias recursivas de una `EXCEPT` cláusula generan un error de conformidad con el estándar ANSI SQL.
La expresión de tabla común (CTE) recursiva permite el uso de nombres de columna duplicados.	Una expresión CTE recursiva no admite nombres de columna duplicados.
Los desencadenadores deshabilitados se habilitan si se modifican los desencadenadores.	Al modificar un desencadenador, no cambia su estado (habilitado o deshabilitado).
La cláusula de la tabla OUTPUT INTO omite `IDENTITY_INSERT SETTING = OFF` y permite que se inserten valores explícitos.	No puede insertar valores explícitos relativos a una columna de identidad en una tabla cuando `IDENTITY_INSERT` está establecido en OFF.
Cuando la contención de la base de datos está establecida en parcial, al validar el campo `$action` en la cláusula `OUTPUT` de una instrucción `MERGE`, se puede devolver un error de intercalación.	La intercalación de los valores devueltos por la cláusula `$action` de una instrucción `MERGE` es la intercalación de la base de datos en lugar de la intercalación del servidor, y no se devuelve un error de conflicto de intercalación.
Una instrucción `SELECT INTO` siempre crea una operación de inserción de subproceso único.	Una instrucción `SELECT INTO` puede crear una operación de inserción en paralelo. Al insertar un gran número de filas, la operación paralela puede mejorar el rendimiento.

Diferencias entre los niveles de compatibilidad inferiores y los niveles 100 y 110

En esta sección se describen nuevos comportamientos incluidos con nivel de compatibilidad 110. Esta sección también se aplica a los niveles de compatibilidad por encima de 110.

Nivel de compatibilidad 100 o inferior	Nivel de compatibilidad de al menos 110
Los objetos de base de datos de Common Language Runtime (CLR) se ejecutan con la versión 4 de CLR. Sin embargo, algunos cambios de comportamiento incluidos en la versión 4 de CLR se evitan. Para más información, vea What's New in CLR Integration (Novedades en la integración con CLR).	Los objetos de base de datos de CLR se ejecutan con la versión 4 de CLR.
Las funciones de XQuery string-length y substring cuentan cada suplente como dos caracteres.	Las funciones de XQuery string-length y substring cuentan cada suplente como un carácter.
`PIVOT` se permite en una consulta de expresión de tabla común (CTE) recursiva. Sin embargo, la consulta devuelve resultados incorrectos cuando hay varias filas por agrupación.	No se permite `PIVOT` en una consulta de expresión de tabla común (CTE) recursiva. Se devuelve un error.
El algoritmo RC4 se admite únicamente por razones de compatibilidad con versiones anteriores. El material nuevo solo se puede cifrar con RC4 o RC4_128 cuando la base de datos tenga el nivel de compatibilidad 90 o 100. (No se recomienda). En SQL Server 2012 (11.x), el material cifrado con RC4 o RC4_128 se puede descifrar en cualquier nivel de compatibilidad.	El nuevo material no se puede cifrar mediante RC4 o RC4_128. Use un algoritmo más reciente como uno de los algoritmos AES en su lugar. En SQL Server 2012 (11.x), el material cifrado con RC4 o RC4_128 se puede descifrar en cualquier nivel de compatibilidad.
El estilo predeterminado de las operaciones `CAST` y `CONVERT` en los tipos de datos time y datetime2 es 121, a menos que se use un tipo en una expresión de columna calculada. Para las columnas calculadas, el estilo predeterminado es 0. Este comportamiento afecta a las columnas calculadas cuando se crean, cuando se utilizan en las consultas que implican parametrización automática o cuando se usan en definiciones de restricciones. En el ejemplo D de la sección Ejemplos se muestra la diferencia entre los estilos 0 y 121. No demuestra el comportamiento descrito anteriormente. Para obtener más información sobre los estilos de fecha y hora, vea CAST y CONVERT.	En el nivel de compatibilidad 110, el estilo predeterminado de las operaciones `CAST` y `CONVERT` en los tipos de datos time y datetime2 es siempre 121. Si su consulta se basa en el comportamiento anterior, use un nivel de compatibilidad menor de 110, o especifique explícitamente el estilo 0 en la consulta correspondiente. Actualizar la base de datos al nivel de compatibilidad 110 no cambiará los datos de usuario que se hayan almacenado en disco. Debe corregir manualmente estos datos según convenga. Por ejemplo, si usa `SELECT INTO` para crear una tabla de un origen que contenía una expresión de columna calculada como la descrita anteriormente, los datos se almacenarían (si se usa el estilo 0) en lugar de la propia definición de columna calculada. Debería actualizar manualmente estos datos para que coincidieran con el estilo 121.
El operador + (Suma) se puede aplicar a un operando de tipo date, time, datetime2 o datetimeoffset si el otro operando tiene el tipo datetime o smalldatetime.	Al intentar aplicar el operador de suma a un operando de tipo date, time, datetime2 o datetimeoffset y un operando de tipo datetime o smalldatetime, se producirá el error 402.
Cualquier columna de las tablas remotas de tipo smalldatetime a la que se haga referencia en una vista con particiones se asignará como datetime. Las columnas correspondientes de tablas locales (en la misma posición ordinal en la lista de selección) deben ser datetime.	Cualquier columna de las tablas remotas de tipo smalldatetime a la que se haga referencia en una vista con particiones se asignará como smalldatetime. Las columnas correspondientes de tablas locales (en la misma posición ordinal en la lista de selección) deben ser smalldatetime. Después de actualizar a 110, la vista distribuida con particiones producirá un error debido a una discrepancia en los tipos de datos. Puede resolver este problema cambiando el tipo de datos en la tabla remota a datetime o estableciendo el nivel de compatibilidad de la base de datos local en 100 o menos.
La función `SOUNDEX` implementa las siguientes reglas: 1) Las letras H o W mayúsculas se omiten al separar dos consonantes que tienen el mismo número del código `SOUNDEX`. 2) Si los dos primeros caracteres de character_expression tienen el mismo número del código de `SOUNDEX`, ambos caracteres se incluyen. Si un conjunto de consonantes en paralelo tiene el mismo número del código de `SOUNDEX`, se excluyen todas excepto la primera.	La función `SOUNDEX` implementa las siguientes reglas: 1) Si H o W mayúsculas separan dos consonantes que tienen el mismo número en el código `SOUNDEX`, se omite la consonante de la derecha. 2) Si un conjunto de consonantes en paralelo tiene el mismo número del código de `SOUNDEX`, se excluyen todas, excepto la primera. Las reglas adicionales pueden hacer que los valores calculados por la `SOUNDEX` función sean diferentes de los valores calculados en niveles de compatibilidad anteriores. Después de actualizar al nivel de compatibilidad 110, es posible que tenga que recompilar los índices, montones o restricciones CHECK que usan la `SOUNDEX` función . Para obtener más información, vea SOUNDEX.
`STRING_AGG` está disponible sin un objeto `<order_clause>`.	`STRING_AGG` está disponible con un objeto `<order_clause>` opcional. Para obtener más información, consulte STRING_AGG.

Diferencias entre los niveles de compatibilidad 90 y 100

En esta sección se describen nuevos comportamientos incluidos con nivel de compatibilidad 100.

Nivel de compatibilidad 90	Nivel de compatibilidad 100	Posibilidad de impacto
La configuración de QUOTED_IDENTIFIER siempre se establece en ON para las funciones con valores de tabla de varios estados cuando se crean independientemente de la configuración de nivel de sesión.	El valor de sesión de QUOTED IDENTIFIER se cumple cuando se crean funciones con valores de tabla con múltiples instrucciones.	Media
Al crear o modificar una función de partición, los literales datetime y smalldatetime de la función se evalúan suponiendo que US_English es la configuración de idioma.	La configuración de idioma actual se usa para evaluar los literales datetime y smalldatetime en la función de partición.	Media
La cláusula `FOR BROWSE` se admite (y se omite) en las instrucciones `INSERT` y `SELECT INTO`.	La cláusula `FOR BROWSE` no se admite en las instrucciones `INSERT` y `SELECT INTO`.	Media
Los predicados de texto completo se permiten en la cláusula `OUTPUT`.	Los predicados de texto completo no se admiten en la cláusula `OUTPUT`.	Bajo
No se admiten `CREATE FULLTEXT STOPLIST`, `ALTER FULLTEXT STOPLIST`, y `DROP FULLTEXT STOPLIST`. La lista de palabras irrelevantes del sistema se asocia automáticamente a nuevos índices de texto completo.	Se admite `CREATE FULLTEXT STOPLIST`, `ALTER FULLTEXT STOPLIST` y `DROP FULLTEXT STOPLIST`.	Bajo
`MERGE` no se aplica como palabra clave reservada.	MERGE es una palabra clave totalmente reservada. La instrucción `MERGE` se admite por debajo de los niveles de compatibilidad 100 y 90.	Bajo
Al usar el argumento <dml_table_source> de la instrucción INSERT, se genera un error de sintaxis.	Puede capturar los resultados de una cláusula OUTPUT en una instrucción anidada INSERT, UPDATE, DELETE o MERGE, e insertar los resultados obtenidos en una vista o tabla de destino. Para ello, es necesario usar el argumento <dml_table_source> de la instrucción INSERT.	Bajo
A menos que se especifique `NOINDEX`, `DBCC CHECKDB` o `DBCC CHECKTABLE` realizan comprobaciones de coherencia física y lógica en una sola tabla o vista indexada, y en todos sus índices XML y no agrupados. Los índices espaciales no se admiten.	A menos que se especifique `NOINDEX`, `DBCC CHECKDB` o `DBCC CHECKTABLE` realizan comprobaciones de coherencia física y lógica en una sola tabla y en todos sus índices no agrupados. Sin embargo, en los índices XML, índices espaciales y vistas indexadas solamente se realizan comprobaciones de coherencia física de forma predeterminada. Si se especifica `WITH EXTENDED_LOGICAL_CHECKS`, se realizan comprobaciones lógicas en las vistas indexadas, índices XML e índices espaciales, si los hay. De forma predeterminada, las comprobaciones de coherencia física se realizan antes que las comprobaciones de coherencia lógica. Si también se especifica `NOINDEX`, solamente se realizarán las comprobaciones lógicas.	Bajo
Cuando una cláusula OUTPUT se utiliza con una instrucción del lenguaje de manipulación de datos (DML) y se produce un error en tiempo de ejecución durante la ejecución de la instrucción, toda la transacción se termina y se revierte.	Cuando una cláusula `OUTPUT` se usa con una instrucción del lenguaje de manipulación de datos (DML) y ocurre un error en tiempo de ejecución durante la ejecución de la instrucción, el comportamiento depende del valor de `SET XACT_ABORT`. Si `SET XACT_ABORT` es OFF, un error de anulación de la instrucción generado por la instrucción DML que usa la cláusula `OUTPUT` terminará la instrucción, pero la ejecución del lote continúa y la transacción no se revierte. Si `SET XACT_ABORT` es ON, todos los errores en tiempo de ejecución generados por la instrucción DML que usa la cláusula OUTPUT terminarán el lote y la transacción se revertirá.	Bajo
CUBE y ROLLUP no se exigen como palabras clave reservadas.	`CUBE` y `ROLLUP` son palabras clave reservadas dentro de la cláusula GROUP BY.	Bajo
A los elementos de tipo anyType de XML se les aplica una validación estricta.	A los elementos de tipo anyType de XML se les aplica una validación flexible. Para más información, vea Componentes comodín y validación del contenido.	Bajo
Los atributos especiales xsi:nil y xsi:type no se pueden consultar ni modificar con instrucciones del lenguaje de manipulación de datos. Esto significa que `/e/@xsi:nil` genera un error mientras que `/e/@` omite los atributos xsi:nil* y xsi:type. En cambio, `/e` devuelve los atributos xsi:nil y xsi:type por coherencia con `SELECT xmlCol`, aun cuando `xsi:nil = "false"`.	Los atributos especiales xsi:nil y xsi:type se almacenan como atributos regulares y se puede consultar y modificar. Por ejemplo, al ejecutar la consulta `SELECT x.query('a/b/@')`, se devuelven todos los atributos incluidos xsi:nil* y xsi:type. Para excluir estos tipos en la consulta, reemplace `@` por `@[namespace-uri(.) != "`insert xsi namespace uri`"` y no `(local-name(.) = "type"` ni `local-name(.) ="nil".`.	Bajo
Una función definida por el usuario que convierte un valor de cadena constante XML en un tipo datetime de SQL Server se marca como determinista.	Una función definida por el usuario que convierte un valor de cadena constante XML en un tipo datetime de SQL Server se marca como no determinista.	Bajo
Los tipos XML de lista y unión no se admiten por completo.	Los tipos de lista y unión que se admiten totalmente incluyen la funcionalidad siguiente: Unión de lista Unión de unión Lista de tipos atómicos Lista de unión	Bajo
Las opciones de SET requeridas para un método de XQuery no se validan cuando el método está contenido en una vista o función con valores de tabla insertados.	Las opciones de SET requeridas para un método de XQuery se validan cuando el método está contenido en una vista o función con valores de tabla insertados. Se produce un error si las opciones de SET del método se establecen incorrectamente.	Bajo
Los valores de los atributos XML que contienen caracteres de fin de línea (retorno de carro y avance de línea) se normalizan de acuerdo con el estándar XML. Es decir, ambos caracteres se devuelven en lugar de un único carácter de avance de línea.	Los valores de los atributos XML que contienen caracteres de fin de línea (retorno de carro y avance de línea) se normalizan de acuerdo con el estándar XML. Es decir, todos los saltos de línea de las entidades externas analizadas (incluidas las de documento) se normalizan en la entrada traduciendo la secuencia de dos caracteres #xD #xA y cualquier #xD al que no siga #xA por un solo carácter #xA. Las aplicaciones que utilizan atributos para transportar los valores de cadena que contienen caracteres de fin de línea no recibirán de vuelta estos caracteres a medida que se envíen. Para evitar el proceso de normalización, utilice entidades de caracteres numéricos XML para codificar todos los caracteres de fin de línea.	Bajo
Las propiedades de columna `ROWGUIDCOL` e `IDENTITY` se pueden denominar incorrectamente como una restricción. Por ejemplo, la instrucción `CREATE TABLE T (C1 int CONSTRAINT MyConstraint IDENTITY)` se ejecuta, pero el nombre de la restricción no se conserva ni es accesible para el usuario.	Las propiedades de columna `IDENTITY` y `ROWGUIDCOL` no se pueden denominar como una restricción. Se devuelve el error 156.	Bajo
Al actualizar las columnas mediante una asignación bidireccional como `UPDATE T1 SET @v = column_name = <expression>`, se pueden generar resultados inesperados porque durante la ejecución de la instrucción se puede usar el valor real de la variable en otras cláusulas como `WHERE` y `ON` en lugar del valor inicial de la instrucción. Esto puede hacer que los significados de los predicados cambien de forma imprevisible según cada fila. Este comportamiento solo es aplicable cuando el nivel de compatibilidad está establecido en 90.	Al actualizar las columnas utilizando una asignación bidireccional, se generan los resultados previstos porque solo se obtiene acceso al valor inicial de la columna de la instrucción durante la ejecución de la misma.	Bajo
La asignación de variables se permite en una instrucción que contiene un operador de nivel `UNION` superior, pero devuelve resultados inesperados. Obtenga más información en el ejemplo E.	No se permite la asignación de variables en una instrucción que contiene un operador UNION de nivel superior. Se devuelve el error 10734. Busque una reescritura sugerida en el ejemplo E.	Bajo
La función ODBC {fn CONVERT()} utiliza el formato de fecha predeterminado del lenguaje. En algunos lenguajes, el formato predeterminado es ADM, lo que puede producir errores de conversión cuando CONVERT() se combina con otras funciones, como `{fn CURDATE()}`, que espera un formato AMD.	La función ODBC `{fn CONVERT()}` usa el estilo 121 (un formato AMD independiente del lenguaje) al convertir a los tipos de datos ODBC SQL_TIMESTAMP, SQL_DATE, SQL_TIME, SQLDATE, SQL_TYPE_TIME y SQL_TYPE_TIMESTAMP.	Bajo
Los intrínsecos datetime, como `DATEPART` no requieren que los valores de entrada de cadena sean literales datetime válidos. Por ejemplo, `SELECT DATEPART (year, '2007/05-30')` se compila correctamente.	Los tipos de fecha y hora intrínsecos como `DATEPART` requieren que los valores de entrada de cadena sean literales de fecha y hora válidos. Se devuelve el error 241 cuando se utiliza un literal de fecha y hora no válido.	Bajo
Los espacios finales especificados en el primer parámetro de entrada para la función REPLACE se recortan cuando el parámetro es de tipo char. Por ejemplo, en la instrucción `SELECT '<' + REPLACE(CONVERT(char(6), 'ABC '), ' ', 'L') + '>'`, el valor `'ABC '` se evalúa incorrectamente como `'ABC'`.	Los espacios finales siempre se conservan. En el caso de las aplicaciones que dependen del comportamiento anterior de la función, use la `RTRIM` función al especificar el primer parámetro de entrada para la función. Por ejemplo, la sintaxis siguiente reproducirá el comportamiento de SQL Server 2005: `SELECT '<' + REPLACE(RTRIM(CONVERT(char(6), 'ABC ')), ' ', 'L') + '>'`.	Bajo

Palabras clave reservadas

El nivel de compatibilidad también determina las palabras clave reservadas por el Motor de base de datos. En la tabla siguiente se muestran las palabras clave reservadas que inserta cada nivel de compatibilidad.

Nivel de compatibilidad	Palabras clave reservadas
130	por determinar.
120	Ninguno.
110	`WITHIN GROUP`, `TRY_CONVERT`, `SEMANTICKEYPHRASETABLE`, , `SEMANTICSIMILARITYDETAILSTABLE`, `SEMANTICSIMILARITYTABLE`
100	`CUBE`, , `MERGE`, `ROLLUP`
90	`EXTERNAL`, `PIVOT`, `UNPIVOT`, , `REVERT`, `TABLESAMPLE`

En un nivel de compatibilidad dado, las palabras clave reservadas incluyen todas las palabras clave insertadas en ese nivel o debajo del mismo. Por ejemplo, para aplicaciones en el nivel 110, todas las palabras clave mostradas en la tabla anterior son reservadas. En los niveles de compatibilidad inferiores, las palabras clave del nivel 100 siguen siendo nombres de objeto válidos, pero las características de idioma del nivel 110 correspondientes a esas palabras clave no están disponibles.

Una vez insertada, una palabra clave permanece reservada. Por ejemplo, la palabra clave reservada PIVOT, que se introdujo en el nivel de compatibilidad 90, también está reservada en los niveles 100, 110 y 120.

Si una aplicación utiliza un identificador que está reservado como palabra clave para su nivel de compatibilidad, la aplicación generará un error. Para resolver este problema, incluya el identificador entre corchetes ( [] ) o comillas ( "" ); por ejemplo, para actualizar una aplicación que usa el identificador EXTERNAL al nivel de compatibilidad 90, puede cambiar el identificador a [EXTERNAL] o "EXTERNAL".

Para obtener más información, vea Palabras clave reservadas.

Permisos

Debe tener el permiso ALTER para la base de datos.

Ejemplos

A. Cambio del nivel de compatibilidad

En el ejemplo siguiente se cambia el nivel de compatibilidad de la AdventureWorks2022base de datos de ejemplo a 150, el valor predeterminado de SQL Server 2019 (15.x).

ALTER DATABASE AdventureWorks2022
SET COMPATIBILITY_LEVEL = 150;
GO

En el siguiente ejemplo se devuelve el nivel de compatibilidad de la base de datos actual.

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

B. Omisión de la instrucción SET LANGUAGE excepto en el nivel de compatibilidad 120 o superior

La consulta siguiente omite la instrucción SET LANGUAGE, excepto en el nivel de compatibilidad 120 o superior.

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

Resultados cuando el nivel de compatibilidad es menor que 120: 12 May 2011

Resultados cuando el nivel de compatibilidad está establecido en 120 o más: 12 mei 2011

C. En el nivel de compatibilidad 110 o inferior, las referencias recursivas en el lado derecho de una cláusula EXCEPT crean un bucle infinito

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. La diferencia entre los estilos 0 y 121

Cuando el nivel de compatibilidad es inferior a 110, el estilo predeterminado de las operaciones CAST y CONVERT en los tipos de datos time y datetime2 es 121, a menos que se use uno de los tipos en una expresión de columna calculada. Para las columnas calculadas, el estilo predeterminado es 0.

Cuando el nivel de compatibilidad es 110 o superior, el estilo predeterminado de las operaciones CAST y CONVERT en los tipos de datos time y datetime2 es siempre 121. Consulte Diferencias entre los niveles de compatibilidad inferiores y los niveles 100 y 110 para obtener más información.

Para más información sobre los estilos de fecha y hora, vea CAST y 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

Esto devuelve resultados como los siguientes:

TimeStyle0	TimeStyle121	Datetime2Style0	Datetime2Style121
3:15PM	15:15:35.8100000	7 de junio de 2011, 15:15	2011-06-07 15:15:35.8130000

E. Asignación de variables - operador UNION de nivel superior

En una configuración de nivel de compatibilidad de la base de datos de 90, la asignación de variables se permite en una instrucción que contenga un operador UNION de nivel superior, pero devuelve resultados inesperados. Por ejemplo, en las instrucciones siguientes, a @v se le asigna el valor de la columna BusinessEntityID a partir de la unión de dos tablas. Por definición, si la instrucción SELECT devuelve más de un valor, se asigna a la variable el último valor devuelto. En este caso, a la variable se le asigna correctamente el último valor, sin embargo, también se devuelve el conjunto de resultados de la instrucción SELECT UNION.

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;

En una configuración de nivel de compatibilidad de la base de datos de 100 y superior, la asignación de variables no se permite en una instrucción que contenga un operador UNION de nivel superior. Se devuelve el error 10734.

Para resolver el error, reescriba la consulta según se muestra en el ejemplo siguiente.

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