Artículo
09/29/2010

Nivel de compatibilidad de ALTER DATABASE (Transact-SQL)

Configura varios comportamientos de la base de datos para que sean compatibles con la versión especificada de SQL Server. Nueva en SQL Server 2008, la siguiente sintaxis de ALTER DATABASE reemplaza al procedimiento sp_dbcmptlevel para establecer el nivel de compatibilidad de la base de datos. Para obtener información acerca de otras opciones de ALTER DATABASE, vea ALTER DATABASE (Transact-SQL).

Icono de vínculo a temas Convenciones de sintaxis de Transact-SQL

Sintaxis

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

Argumentos

database_name
Es el nombre de la base de datos que se va a modificar.
COMPATIBILITY_LEVEL { 80 | 90 | 100 }
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:

80 = SQL Server 2000

90 = SQL Server 2005

100 = SQL Server 2008

Notas

Para todas las instalaciones de SQL Server 2008, el nivel de compatibilidad predeterminado es 100. Las bases de datos creadas en SQL Server 2008 están establecidas en este nivel a menos que la base de datos model tenga un nivel de compatibilidad más bajo. Cuando se actualiza una base de datos a SQL Server 2008 desde una versión anterior de SQL Server, la base de datos mantiene su nivel de compatibilidad si es al menos 80. La actualización de una base de datos con un nivel de compatibilidad menor de 80 establece el nivel de compatibilidad en 80. 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 sólo al comportamiento de la base de datos especificada y no a todo el servidor. El nivel de compatibilidad sólo 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 del nivel de compatibilidad correspondiente. Si tiene aplicaciones de SQL Server que se ven afectadas por las diferencias de comportamiento en SQL Server 2008, 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:

Establezca la base de datos en modo de acceso de usuario único mediante ALTER DATABASE SET SINGLE_USER.
Cambie el nivel de compatibilidad de la base de datos.
Coloque la base de datos en modo de acceso multiusuario mediante ALTER DATABASE SET MULTI_USER.
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).

Opciones SET

Es posible que las nuevas funciones funcionen con niveles de compatibilidad anteriores, pero las opciones SET pueden necesitar ajustes. Por ejemplo, el uso del tipo de datos xml con el nivel de compatibilidad 80 requiere las opciones adecuadas de ANSI SET. Además, cuando el nivel de compatibilidad de la base de datos está establecido en 90 o en un nivel superior, al configurar ANSI_WARNINGS en ON se establece de forma implícita ARITHABORT en ON. Si el nivel de compatibilidad de la base de datos está establecido en 80, es necesario establecer la opción ARITHABORT en ON de forma explícita . Para obtener más información, vea Opciones SET que afectan a los resultados.

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 80 y 90

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

En el nivel de compatibilidad 90, se producen los siguientes cambios de comportamiento.

Nivel de compatibilidad 80	Nivel de compatibilidad 90	Posibilidad de impacto
Para las sugerencias de bloqueo de la cláusula FROM, la palabra clave WITH es siempre opcional.	Con algunas excepciones, las sugerencias de tabla únicamente se admiten en la cláusula FROM cuando las sugerencias se especifican con la palabra clave WITH. Para obtener más información, vea FROM (Transact-SQL).	Alta
Los operadores de combinación externa = e = se admiten con un mensaje de advertencia.	Estos operadores no se admiten; es necesario utilizar la palabra clave OUTER JOIN.	Alta
Al enlazar las referencias a columnas de la lista ORDER BY con las columnas definidas en la lista SELECT, no se tienen en cuenta las ambigüedades de las columnas y, en ocasiones, tampoco los prefijos de columna. Esto puede hacer que el conjunto de resultados se devuelva en un orden inesperado. Por ejemplo, se acepta una cláusula ORDER BY compuesta por una sola columna de dos partes (<table_alias>.<column>) que se utiliza para hacer referencia a un alias de columna en una lista SELECT, pero se omite el alias de la tabla. Estudie la siguiente consulta. SELECT c1 = -c1 FROM t_table AS x ORDER BY x.c1 Cuando se ejecuta, el prefijo de columna se omite en la cláusula ORDER BY. La operación de ordenación no se realiza en la columna de origen especificada (x.c1) como se esperaba, sino en la columna c1 derivada que se define en la consulta. El plan de ejecución para esta consulta muestra que los valores de la columna derivada se calculan primero y después se ordenan los valores calculados.	Se generan errores si hay ambigüedad en las columnas. Los prefijos de columna especificados en ORDER BY, en caso de que haya, no se omiten al enlazar con una columna definida en la lista SELECT. Estudie la siguiente consulta. SELECT c1 = -c1 FROM t_table AS x ORDER BY x.c1 Cuando se ejecuta, el prefijo de columna no se omite en la cláusula ORDER BY. La operación de ordenación se realiza en la columna de origen especificada (x.c1) como se esperaba. El plan de ejecución para esta consulta muestra que el operador SORT ordena las filas devueltas por t_table y después se calculan los valores para la columna derivada c1 definida en la lista SELECT.	Media
En una instrucción INSERT SELECT de una unión (UNION) de distintos tipos de datos, cada rama de la unión se convierte directamente al tipo de la columna de destino de INSERT. Aunque la unión utilizada pudiese generar un error por sí misma debido a una conversión de tipos incompatible, INSERT SELECT hace que UNION sea correcto porque nunca se convierte la rama al tipo de resultado de UNION.	El tipo de resultado de UNION se deriva independientemente de INSERT SELECT. Cada rama de UNION se convierte al tipo de resultado de UNION y, a continuación, se convierte al tipo de columna de destino de INSERT. Si hay tipos incompatibles en UNION, la primera conversión podría generar un error. Para funcionar en el nivel de compatibilidad 90, es necesario reparar todas las uniones de tipos incompatibles que se utilizan dentro de INSERT SELECT.	Media
La compatibilidad con operaciones de inserción y actualización a través de una vista es incorrecta en las vistas que especifican la cláusula WITH CHECK OPTION cuando la vista, o una vista a la que se hace referencia, utiliza la cláusula TOP.	No existe compatibilidad con operaciones de inserción y actualización a través de una vista para las vistas que especifican WITH CHECK OPTION cuando la vista, o una vista a la que se hace referencia, utiliza la cláusula TOP.	Media
La unión de una columna de longitud variable y una columna de longitud fija genera una columna de longitud fija.	La unión de una columna de longitud variable y una columna de longitud fija genera una columna de longitud variable.	Media
SET XACT_ABORT OFF se omite dentro de un desencadenador. La opción siempre está establecida en ON.	SET XACT_ABORT se puede establecer en OFF dentro de un desencadenador.	Media
La cláusula FOR BROWSE se admite (y se omite) en las vistas.	La cláusula FOR BROWSE no se admite en las vistas.	Media
Los errores de dominio no se controlan mediante ANSI_WARNINGS. Se admiten los niveles de ARITHABORT, si ANSI_WARNINGS se establece en OFF y si no se produce ningún cambio en ARITHABORT.	Los errores de dominio se controlan también mediante ANSI_WARNINGS y son errores de gravedad 16. Si ANSI_WARNINGS o ARITHABORT está establecido en ON, se genera un error en lugar de devolver un valor NULL. Es posible que los scripts de usuario que dependan de que ARITHABORT se establezca en OFF se interrumpan por este cambio.	Media
Si una consulta de paso a través en un origen de datos remoto [OPENROWSET o OPENQUERY] genera columnas con nombres duplicados, se omitirán los nombres de columna duplicados a menos que las columnas se mencionen explícitamente en la consulta.	Si una consulta de paso a través en un origen de datos remoto [OPENROWSET o OPENQUERY] genera una columna con nombres de columna duplicados, se produce un error.	Baja
Las constantes de tipo cadena de caracteres y las constantes de tipo varbinary cuyo tamaño sea superior a 8000 se tratan como text, ntext o image.	Las constantes de tipo cadena de caracteres y las constantes de tipo varbinary cuyo tamaño sea superior a 8000 se tratan como de tipo varchar(max) (o nvarchar(max) y varbinary(max), respectivamente). Este comportamiento puede cambiar el tipo de datos de una tabla creada mediante SELECT … INTO si la lista SELECT contiene estas expresiones.	Baja
Las comparaciones entre tipos numéricos (smallint, tinyint, int, bigint, numeric, decimal, smallmoney, money) se realizan convirtiendo el comparando con menor prioridad de la jerarquía de tipos al tipo cuya prioridad sea mayor.	Los valores de tipo numérico se comparan sin conversión. Esto mejora el rendimiento. Sin embargo, puede producir algunos cambios de comportamiento, sobre todo cuando la conversión causa excepciones por desbordamiento.	Baja
Las funciones de metadatos integradas que utilizan argumentos de cadena truncan su entrada si ésta es superior a 4000 caracteres.	Las funciones de metadatos integradas generan un error si, debido al truncamiento, se pueden perder caracteres que no sean espacios.	Baja
El grupo de caracteres no permitidos en un identificador sin comillas permanece invariable.	El analizador de Transact-SQL admite el estándar Unicode 3.2, que modifica la clasificación de caracteres para algunos caracteres internacionales cuyo uso ahora no está permitido en los identificadores sin delimitar.	Baja
SET ANSI_WARNINGS ON no invalida el valor de SET ARITHABORT OFF en el caso de los errores de dominio de punto flotante, es decir, argumentos negativos para la función log(). Si ANSI_WARNINGS está establecido en ON pero ARITHABORT lo está en OFF, los errores de dominio de punto flotante no provocan la finalización de la consulta.	SET ANSI_WARNINGS ON invalida completamente el valor de ARITHABORT OFF. En este caso, los errores de dominio de punto flotante hacen que la consulta finalice.	Baja
Se permiten (y omiten) las constantes no enteras en la cláusula ORDER BY.	No se permiten las constantes no enteras en la cláusula ORDER BY.	Baja
Se permiten las instrucciones SET vacías (sin asignaciones de opciones SET).	No se admite una cláusula SET vacía.	Baja
El atributo IDENTITY no se deriva correctamente para las columnas producidas por una tabla derivada.	El atributo IDENTITY se deriva correctamente para las columnas producidas por tablas derivadas.	Baja
La propiedad de nulabilidad de los operadores aritméticos en los tipos de datos de punto flotante es que siempre se aceptan los valores NULL.	La propiedad de nulabilidad de los operadores aritméticos en los tipos de datos de punto flotante pasa a ser que no se admiten valores NULL cuando las entradas no admiten valores NULL y ANSI_WARNINGS es ON.	Baja
En la instrucción INSERT .. .. SELECT con UNION, todos los tipos generados en los conjuntos de resultados individuales se convierten al tipo de resultado de destino.	En la instrucción INSERT .. .. SELECT con UNION, se determina el tipo dominante de las distintas ramas y los resultados se convierten a ese tipo antes de ser convertidos al tipo de la tabla de destino.	Baja
En la instrucción SELECT .. FOR XML, siempre se crean entidades para hex(27) (el carácter ') y hex(22) (el carácter "), aunque no sea necesario.	FOR XML crea entidades para hex(27) y hex(22) sólo cuando es necesario. No se crean entidades para ellos en las siguientes situaciones: En el contenido de los atributos, no se crea una entidad para hex(27) (el carácter ') si los valores de los atributos están delimitados con ", y no se crea una entidad para hex(22) (el carácter ") si los valores de los atributos están delimitados con '. En el contenido de los elementos, nunca se crean entidades para hex(27) y hex(22).	Baja
En FOR XML, el valor de marca de tiempo se asigna a un entero.	En FOR XML, el valor de marca de tiempo se asigna a un valor binario. Para obtener más información, vea Compatibilidad de FOR XML con el tipo de datos de marca de tiempo.	Alta (si se usa una columna timestamp); en caso contrario, Baja
En FOR XML y OPENXML, los caracteres Unicode de rango alto (3 bytes) en los nombres se representan utilizando 8 posiciones. Por ejemplo, utilizando 8 posiciones, FOR XML representa el punto de código Unicode U+10000 como: <a_x00010000_ c1="1" />	En FOR XML y OPENXML, los caracteres Unicode de rango alto (3 bytes) en los nombres se representan utilizando 6 posiciones. Por ejemplo, utilizando 6 posiciones, FOR XML representa el punto de código Unicode U+10000 como: <a_x010000_ c1="1" />	Baja
En FOR XML, las asignaciones de tablas derivadas en modo AUTO se tratan de manera transparente. Por ejemplo: `USE AdventureWorks CREATE TABLE Test(id int); INSERT INTO Test VALUES(1); INSERT INTO Test VALUES(2); SELECT * FROM (SELECT a.id AS a, b.id AS b FROM Test a JOIN Test b ON a.id=b.id) Test FOR XML AUTO;` Cuando el nivel de compatibilidad de AdventureWorks se establece en 80, el ejemplo anterior genera el siguiente resultado: <a a="1"><b b="1"/></a> <a a="2"><b b="2"/></a>	En FOR XML, las asignaciones de tablas derivadas en modo AUTO se tratan de manera opaca. Cuando el nivel de compatibilidad de AdventureWorks se establece en 90, el ejemplo anterior genera el siguiente resultado: <Test a="1" b="1"/> <Test a="2" b="2"/>	Alta si el modo AUTO de FOR XML se aplica a las vistas; en caso contrario, es Baja
En las conversiones de cadena al tipo money se permite el uso de la barra diagonal inversa (\) como símbolo de moneda sólo en los idiomas japonés y coreano.	La barra diagonal inversa (\) se acepta en todas las conversiones de cadena al tipo money en todos los idiomas. ISNUMERIC devolvería True si se utilizase \ como símbolo de moneda. En bases de datos de versiones de SQL Server anteriores a SQL Server 2005, este nuevo comportamiento separa los índices y las columnas calculadas que dependen de un valor devuelto de ISNUMERIC que contiene \ y cuyo idioma no es japonés ni coreano.	Baja
El resultado de un operador aritmético siempre acepta valores NULL, incluso aunque los operandos no acepten valores NULL y ANSI_WARNINGS o ARITHABORT se haya establecido en ON.	Cuando ANSI_WARNINGS o ARITHABORT se establece en ON, el resultado de un operador aritmético de punto flotante no acepta valores NULL si ambos operandos no los aceptan. Este cambio en la nulabilidad podría generar errores si se utiliza bcp para exportar de forma masiva datos que utilizan el formato binario de una tabla de SQL Server 2000 con una columna calculada que utiliza un operador aritmético de punto flotante y después se utiliza bcp o BULK INSERT para importar de forma masiva esos datos a una tabla de SQL Server 2005 con la misma definición. Nota Cuando ambas opciones están establecidas en OFF, el Database Engine (Motor de base de datos) marca el resultado para aceptar valores NULL. Ocurre lo mismo que en SQL Server 2000.	Baja
Para las funciones integradas que utilizan nvarchar como parámetro, si el valor suministrado es de tipo varchar, el valor se convierte a nvarchar (4000). En SQL Server 2000, si se pasa un valor mayor, se trunca de manera silenciosa.	Para las funciones integradas que utilizan nvarchar como parámetro, si el valor suministrado es de tipo varchar, el valor todavía se convierte a nvarchar (4000). Sin embargo, si se pasa un valor mayor, SQL Server 2008 genera un error. Para trabajar en el nivel de compatibilidad 90, debe reparar el código personalizado que se base en el comportamiento de truncamiento.	Baja
Una unión de una cadena de longitud fija (char, binary o nchar) y una cadena de longitud variable (varchar, varbinary, nvarchar) devuelve un resultado de longitud fija.	La unión de una cadena de tamaño variable y una cadena de tamaño fijo devuelve una cadena de tamaño variable. Para trabajar en el nivel de compatibilidad 90, debe reparar todos los elementos (índices, consultas y columnas calculadas) que dependan del tipo resultante de una unión de un tipo de tamaño variable y un tipo de tamaño fijo.	Baja
Los nombres de objeto que contienen el carácter 0xFFFF son identificadores válidos.	Los nombres de objetos que contienen el carácter 0xFFFF no son identificadores válidos y no se puede tener acceso a ellos. Para trabajar en el nivel de compatibilidad 90, debe cambiar el nombre de los objetos que contengan este carácter.	Baja
En SELECT ISNUMERIC('<string>'), las comas incrustadas incluidas en <string> son significativas. Por ejemplo, la siguiente consulta SELECT ISNUMERIC('121212,12') devuelve 0. Esto indica que la cadena 121212,12 no es numérica.	En SELECT ISNUMERIC('<string>'), se omiten las comas incrustadas incluidas en <string>. Por ejemplo, la siguiente consulta SELECT ISNUMERIC('121212,12') devuelve 1. Esto indica que la cadena 121212,12 es numérica.	Baja
El signo de dos puntos (:) que siguen a una palabra clave reservada en una instrucción de Transact-SQL se omitirá.	El signo de dos puntos (:) que sigue a una palabra clave reservada en una instrucción de Transact-SQL provocará un error en la instrucción.	Baja
Una cláusula GROUP BY de una subconsulta que hace referencia a una columna de la consulta externa se ejecuta correctamente.	Una cláusula GROUP BY de una subconsulta que hace referencia a una columna de la consulta externa devuelve un error según el estándar SQL.	Baja

Diferencias entre los niveles de compatibilidad inferiores y el nivel 100

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

Palabras clave reservadas

El nivel de compatibilidad también determina las palabras clave reservadas por el Database Engine (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
100	CUBE, MERGE, ROLLUP
90	EXTERNAL, PIVOT, UNPIVOT, REVERT, TABLESAMPLE
80	COLLATE, FUNCTION, OPENXML

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 100, 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 100 correspondientes a esas palabras clave no están disponibles.

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

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 AdventureWorks a 90,SQL Server 2005.

ALTER DATABASE AdventureWorks
SET COMPATIBILITY_LEVEL = 90;
GO

B. Efecto del nivel de compatibilidad en ORDER BY (escenario 1)

En el ejemplo siguiente se muestra la diferencia del enlace ORDER BY para los niveles de compatibilidad 80 y 100. Se crea la tabla de ejemplo SampleTable en la base de datos tempdb.

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

En el nivel de compatibilidad 90 y superiores, que es el predeterminado, la siguiente instrucción SELECT... ORDER BY genera un error porque el alias de la columna de la cláusula AS, c1, es ambiguo.

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

Después de restablecer la base de datos al nivel de compatibilidad 80, la misma instrucción SELECT... ORDER BY se ejecuta correctamente.

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

La instrucción SELECT... ORDER BY siguiente funciona en ambos niveles de compatibilidad porque se especifica un alias inequívoco en la cláusula AS.

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

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

C. Efecto del nivel de compatibilidad en ORDER BY (escenario 2)

En el nivel de compatibilidad 90 y superiores, que es el nivel predeterminado, la instrucción SELECT...ORDER BY siguiente genera un error porque el alias de columna especificado en la cláusula ORDER BY contiene un prefijo de tabla.

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

Después de restablecer la base de datos al nivel de compatibilidad 80, la misma instrucción SELECT...ORDER BY se ejecuta correctamente.

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

La instrucción SELECT...ORDER BY siguiente funciona en ambos niveles de compatibilidad porque el prefijo de la tabla se quita del alias de columna especificado en la cláusula ORDER BY.

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

Historial de cambios

Contenido actualizado
Corregido el comportamiento de la instrucción XACT_ABORT cuando se especifica dentro de un desencadenador. Si se establece XACT_ABORT en OFF en un desencadenador, se omite en el nivel de compatibilidad 80 y se permite en el nivel de compatibilidad 90 o superiores. En la documentación anterior se invirtió esta información.

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)

Conceptos

Opción del nivel de compatibilidad de la base de datos

Compartir a través de