Nivel de compatibilidad de ALTER DATABASE (Transact-SQL)

Configura varios comportamientos de la base de datos de manera que sean compatibles con la versión especificada de SQL Server. Para obtener información acerca de otras opciones de ALTER DATABASE, vea ALTER DATABASE (Transact-SQL).

Convenciones de sintaxis de Transact-SQL

Sintaxis

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

Argumentos

• database_name
  Es el nombre de la base de datos que se va a modificar.

• COMPATIBILITY_LEVEL { 90 | 100 | 110 }
  Es la versión de SQL Server con la que se va a hacer compatible la base de datos. Debe tener uno de los siguientes valores:

  90 = SQL Server 2005

  100 = SQL Server 2008 y SQL Server 2008 R2

  110 = SQL Server 2012

Comentarios

Para todas las instalaciones de SQL Server 2012, el nivel de compatibilidad predeterminado es 110. Las bases de datos creadas en SQL Server 2012 están establecidas en este nivel a menos que la base de datos modelo tenga un nivel de compatibilidad más bajo. Cuando se actualiza una base de datos a SQL Server 2012 desde una versión anterior de SQL Server, la base de datos mantiene su nivel de compatibilidad si es al menos 90. La actualización de una base de datos con un nivel de compatibilidad menor de 90 establece el nivel de compatibilidad en 90. Esto se aplica a las bases de datos del usuario y del sistema. Utilice ALTER DATABASE para cambiar el nivel de compatibilidad de la base de datos. 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.

Usar el nivel de compatibilidad para la compatibilidad con versiones anteriores

El nivel de compatibilidad afecta solo al comportamiento de la base de datos especificada y no a todo el servidor. El nivel de compatibilidad solo proporciona compatibilidad parcial con versiones anteriores de SQL Server. Use el nivel de compatibilidad como ayuda provisional para la migración, para solucionar diferencias de comportamiento entre las versiones que se controlan con el valor de nivel de compatibilidad correspondiente. Si tiene aplicaciones de SQL Server que se ven afectadas por las diferencias de comportamiento en SQL Server 2012, conviértalas para que funcionen correctamente. A continuación, utilice ALTER DATABASE para cambiar el nivel de compatibilidad a 100. El nuevo nivel de compatibilidad para una base de datos se hace efectivo la próxima vez que se actualice la base de datos (ya sea como la base de datos predeterminada al iniciar sesión o al especificarse en una instrucción USE).

Prácticas recomendadas

Si se cambia el nivel de compatibilidad mientras hay usuarios conectados a la base de datos, pueden producirse conjuntos de resultados incorrectos para las consultas activas. Por ejemplo, si el nivel de compatibilidad cambia mientras se está compilando un plan de consulta, es posible que el plan compilado se base en los niveles de compatibilidad nuevo y antiguo, lo que produciría un plan incorrecto y, posiblemente, resultados imprecisos. Además, el problema puede agravarse si se coloca el plan en la memoria caché de plan y se reutiliza en consultas sucesivas. Para evitar resultados de consulta no exactos, se recomienda el siguiente procedimiento para cambiar el nivel de compatibilidad de una base de datos:

1. Establezca la base de datos en modo de acceso de usuario único mediante ALTER DATABASE SET SINGLE_USER.

2. Cambie el nivel de compatibilidad de la base de datos.

3. Coloque la base de datos en modo de acceso multiusuario mediante ALTER DATABASE SET MULTI_USER.

4. Para obtener más información acerca de cómo establecer el modo de acceso de una base de datos, vea ALTER DATABASE (Transact-SQL).

Niveles de compatibilidad y procedimientos almacenados

Cuando se ejecuta un procedimiento almacenado, se utiliza 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.

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
El valor QUOTED_IDENTIFER siempre está establecido en ON para las funciones con valores de tabla con múltiples instrucciones cuando se crean sin tener en cuenta el valor 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 utiliza para evaluar los literales datetime y smalldatetime en la función de partición.	Media
La cláusula FOR BROWSE se permite (y se omite) en las instrucciones SELECT INTO e INSERT.	La cláusula FOR BROWSE no se permite en las instrucciones SELECT INTO e INSERT.	Media
Los predicados de texto completo se permiten en la cláusula OUTPUT.	Los predicados de texto completo no se permiten en la cláusula OUTPUT.	Baja
No se admiten CREATE FULLTEXT STOPLIST, ALTER FULLTEXT STOPLIST o DROP FULLTEXT STOPLIST. La lista de palabras irrelevantes del sistema se asocia automáticamente a nuevos índices de texto completo.	Se admiten CREATE FULLTEXT STOPLIST, ALTER FULLTEXT STOPLIST o DROP FULLTEXT STOPLIST.	Baja
MERGE no se aplica como una 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.	Baja
Al utilizar 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 utilizar el argumento <dml_table_source> de la instrucción INSERT.	Baja
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 indizada, y en todos sus índices XML y no clúster. 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 clúster. Sin embargo, en los índices XML, índices espaciales y vistas indizadas 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 indizadas, í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.	Baja
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 utiliza 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á.	Baja
CUBE y ROLLUP no se exigen como palabras clave reservadas.	CUBE y ROLLUP son palabras clave reservadas dentro de la cláusula GROUP BY.	Baja
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 obtener más información, vea Componentes comodín y validación del contenido.	Baja
Los atributos especiales xsi:nil y xsi:type no se pueden consultar ni modificar mediante instrucciones del lenguaje de manipulación de datos (DML). Esto significa que /e/@xsi:nil genera un error mientras que /e/@* omite los atributos xsi:nil y xsi:type. Sin embargo, /e devuelve los atributos xsi:type y xsi:nil 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 @* con @*[namespace-uri(.) != "insert xsi namespace uri" y no (local-name(.) = "type" o local-name(.) ="nil".	Baja
Una función definida por el usuario que convierta 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 convierta un valor de cadena constante XML a un tipo datetime de SQL Server se marca como no determinista.	Baja
Los tipos de lista y unión de XML 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	Baja
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) no se normalizan según 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.	Baja
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 restricción no se conserva y no es accesible para el usuario.	Las propiedades de columna ROWGUIDCOL e IDENTITY no se pueden denominar como una restricción. Se devuelve el error 156.	Baja
Al actualizar las columnas utilizando 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 utilizar 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.	Baja
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 AdventureWorks2012 SET compatibility_level = 90; GO USE AdventureWorks2012; GO DECLARE @v int; SELECT @v = BusinessEntityID FROM HumanResources.Employee UNION ALL SELECT @v = BusinessEntityID FROM HumanResources.EmployeeAddress; SELECT @v;	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. 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;	Baja
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()} utiliza 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.	Baja
La función ODBC {fn CURDATE()} devuelve solo la fecha en el formato 'AAAA-MM-DD'.	La función ODBC {fn CURDATE()} devuelve tanto la fecha como la hora, por ejemplo 'AAAA-MM-DD hh:mm:ss'.	Baja
Los tipos de fecha y hora intrínsecos como DATEPART no requieren que los valores de entrada de cadena sean literales de fecha y hora válidos. Por ejemplo, SELECT DATEPART (year, 2007/05-30') se compila correctamente.	Los tipos de fecha intrínsecos y hora 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.	Baja

Diferencias entre los niveles de compatibilidad inferiores y el nivel 110

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

Nivel de compatibilidad 100 o inferior	Nivel de compatibilidad 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 obtener más información, vea Novedades de la integración con CLR.	Los objetos de base de datos de CLR se ejecutan con la versión 4 de CLR.
Las funciones string-length y substring de XQuery cuentan cada suplente como dos caracteres.	Las funciones string-length y substring de XQuery 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.	PIVOT no se permite en una consulta de expresión de tabla común (CTE) recursiva. Se devuelve un error.
El algoritmo RC4 se admite solo por compatibilidad con versiones anteriores. El material nuevo sólo se puede cifrar con RC4 o RC4_128 cuando la base de datos tenga el nivel de compatibilidad 90 ó 100. (No se recomienda). En SQL Server 2012, 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, 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 utilice 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 siguiente se muestra la diferencia entre los estilos 0 y 121. No se muestra el comportamiento descrito anteriormente. Para obtener más información sobre los estilos de fecha y hora, vea CAST y CONVERT (Transact-SQL). CREATE TABLE t1 (c1 time(7), c2 datetime2); INSERT t1 (c1,c2) VALUES (GETDATE(), GETDATE()); SELECT CONVERT(nvarchar(16),c1,0) AS TimeStyle0 ,CONVERT(nvarchar(16),c1,121)AS TimeStyle121 ,CONVERT(nvarchar(32),c2,0) AS Datetime2Style0 ,CONVERT(nvarchar(32),c2,121)AS Datetime2Style121 FROM t1; -- Returns values such as the following. TimeStyle0 TimeStyle121 Datetime2Style0 Datetime2Style121 ---------------- ---------------- -------------------- -------------------------- 3:15PM 15:15:35.8100000 Jun 7 2011 3:15PM 2011-06-07 15:15:35.8130000	Bajo 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 utilizara SELECT INTO para crear una tabla de un origen que contuviera una expresión de columna calculada como la descrita anteriormente, se almacenarían los datos (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.
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 reglas siguientes: Las letras H o W mayúsculas se omiten al separar dos consonantes que tienen el mismo número del código SOUNDEX. Si los 2 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 reglas siguientes: 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. 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 causar que los valores calculados por la función SOUNDEX sean diferentes de los calculados en niveles de compatibilidad menores. Después de actualizar al nivel de compatibilidad 110, es posible que tenga que recompilar los índices, los montones o las restricciones CHECK que utilizan la función SOUNDEX. Para obtener más información, vea SOUNDEX (Transact-SQL).

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
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 insertó en el nivel de compatibilidad 90, también está reservada en los niveles 100 y 110.

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 (Transact-SQL).

Permisos

Requiere el permiso ALTER en la base de datos.

Ejemplos

A.Cambiar el nivel de compatibilidad

En el ejemplo siguiente se cambia el nivel de compatibilidad de la base de datos AdventureWorks2012 a 110, SQL Server 2012.

ALTER DATABASE AdventureWorks2012
SET COMPATIBILITY_LEVEL = 110;
GO

Vea también

Referencia

ALTER DATABASE (Transact-SQL)

Palabras clave reservadas (Transact-SQL)

CREATE DATABASE (Transact-SQL)

DATABASEPROPERTYEX (Transact-SQL)

sys.databases (Transact-SQL)

sys.database_files (Transact-SQL)