Cambios de comportamiento en las características del motor de base de datos en SQL Server 2014

En este tema se describen los cambios de comportamiento en el motor de base de datos. Los cambios de comportamiento afectan a cómo funcionan o interactúan las características en SQL Server 2014 en comparación con las versiones anteriores de SQL Server.

Cambios de comportamiento en SQL Server 2014

En versiones anteriores de SQL Server, las consultas en un documento XML que contiene cadenas de una longitud determinada (más de 4020 caracteres) pueden devolver resultados incorrectos. En SQL Server 2014, estas consultas devuelven los resultados correctos.

Cambios de comportamiento en SQL Server 2012

Detección de metadatos

Las mejoras en el motor de base de datos a partir de SQL Server 2012 permiten a SQLDescribeCol obtener descripciones más precisas de los resultados esperados que los devueltos por SQLDescribeCol en versiones anteriores de SQL Server. Para obtener más información, vea Detección de metadatos.

La opción SET FMTONLY para determinar el formato de una respuesta sin ejecutar realmente la consulta se reemplaza por sp_describe_first_result_set (Transact-SQL), sp_describe_undeclared_parameters (Transact-SQL), sys.dm_exec_describe_first_result_set (Transact-SQL)y sys.dm_exec_describe_first_result_set_for_object (Transact-SQL).

Cambios en el comportamiento al crear un script para una tarea de SQL Server Agent

A partir de SQL Server 2012, si crea un nuevo trabajo copiando el script de un trabajo existente, el nuevo trabajo podría afectar involuntariamente al trabajo existente. Para crear un nuevo trabajo mediante el script de un trabajo existente, elimine manualmente el parámetro @schedule_uid que suele ser el último parámetro de la sección que crea la programación del trabajo en el trabajo existente. Esto creará una nueva programación independiente para el nuevo trabajo sin afectar a los trabajos existentes.

Plegado constante para funciones y métodos clR User-Defined

A partir de SQL Server 2012, ahora se pueden plegar los siguientes objetos CLR definidos por el usuario:

• Funciones definidas por el usuario CLR con valores escalares deterministas.
• Métodos deterministas de tipos definidos por el usuario CLR.

Esta mejora busca mejorar el rendimiento cuando se llama a estas funciones o métodos más de una vez con los mismos argumentos. Sin embargo, este cambio puede provocar resultados inesperados cuando las funciones o métodos no deterministas se han marcado como deterministas en error. El determinismo de una función o método CLR se indica mediante el valor de la IsDeterministic propiedad de SqlFunctionAttribute o SqlMethodAttribute.

El comportamiento del método STEnvelope() ha cambiado con tipos espaciales vacíos

El comportamiento del STEnvelope método con objetos vacíos ahora es coherente con el comportamiento de otros métodos espaciales de SQL Server.

En SQL Server 2008, el STEnvelope método devolvió los siguientes resultados cuando se llama con objetos vacíos:

SELECT geometry::Parse('POINT EMPTY').STEnvelope().ToString()  
-- returns POINT EMPTY  
SELECT geometry::Parse('LINESTRING EMPTY').STEnvelope().ToString()  
-- returns LINESTRING EMPTY  
SELECT geometry::Parse('POLYGON EMPTY').STEnvelope().ToString()  
-- returns POLYGON EMPTY  

En SQL Server 2012, el STEnvelope método ahora devuelve los siguientes resultados cuando se llama con objetos vacíos:

SELECT geometry::Parse('POINT EMPTY').STEnvelope().ToString()  
-- returns GEOMETRYCOLLECTION EMPTY  
SELECT geometry::Parse('LINESTRING EMPTY').STEnvelope().ToString()  
-- returns GEOMETRYCOLLECTION EMPTY  
SELECT geometry::Parse('POLYGON EMPTY').STEnvelope().ToString()  
-- returns GEOMETRYCOLLECTION EMPTY  

Para determinar si un objeto espacial está vacío, llame al método STIsEmpty (geometry tipo de datos).

La función LOG tiene un nuevo parámetro opcional

La LOG función ahora tiene un parámetro base opcional. Para obtener más información, vea LOG (Transact-SQL).

El cálculo de estadísticas durante las operaciones de índice particionado ha cambiado

En SQL Server 2014, las estadísticas no se crean mediante el examen de todas las filas de la tabla cuando se crea o se vuelve a generar un índice con particiones. En su lugar, el optimizador de consultas usa el algoritmo de muestreo predeterminado para generar estadísticas. Después de actualizar una base de datos con índices con particiones, es posible que observe una diferencia en los datos del histograma de estos índices. Este cambio en el comportamiento puede no afectar al rendimiento de las consultas. Para obtener estadísticas sobre índices con particiones examinando todas las filas de la tabla, use CREATE STATISTICS o UPDATE STATISTICS con la cláusula FULLSCAN.

Conversión de tipos de datos por el método de valor XML ha cambiado

El comportamiento interno del value método del xml tipo de datos ha cambiado. Este método realiza una XQuery en el XML y devuelve un valor escalar del tipo de datos de SQL Server especificado. El tipo xs debe convertirse en el tipo de datos de SQL Server. Anteriormente, el value método convertía internamente el valor de origen en una cadena xs:string y, a continuación, convertía la cadena xs:string al tipo de datos de SQL Server. En SQL Server 2014, la conversión a xs:string se omite en los casos siguientes:

El nuevo comportamiento mejora el rendimiento cuando se puede omitir la conversión intermedia. Sin embargo, cuando se produce un error en las conversiones de tipos de datos, se ven mensajes de error diferentes a los que se generaron al convertir desde el valor intermedio xs:string. Por ejemplo, si el método value no pudo convertir el int valor 100000 en , smallintel mensaje de error anterior era:

The conversion of the nvarchar value '100000' overflowed an INT2 column. Use a larger integer column.

En SQL Server 2014, sin la conversión intermedia a xs:string, el mensaje de error es:

Arithmetic overflow error converting expression to data type smallint.

sqlcmd.exe cambio de comportamiento en modo XML

Hay cambios de comportamiento si usa sqlcmd.exe con el modo XML (comando:XML ON) al ejecutar un SELECT * desde T FOR XML ...

Mensaje revisado de DBCC CHECKIDENT

En SQL Server 2012, el mensaje devuelto por el comando DBCC CHECKIDENT solo ha cambiado cuando se usa con RESEED new_reseed_value para cambiar el valor de identidad actual. El nuevo mensaje es "Comprobando la información de identidad: valor de identidad actual '<valor de identidad actual>'" Ejecución de DBCC completada. Si DBCC imprime mensajes de error, póngase en contacto con el administrador del sistema".

En versiones anteriores, el mensaje es "Comprobación de la información de identidad: valor de identidad actual '<valor de identidad actual>', valor de columna actual '<valor de columna actual>'. Ejecución de DBCC completada. Si DBCC imprimió mensajes de error, póngase en contacto con el administrador del sistema". El mensaje no cambia cuando DBCC CHECKIDENT se especifica con NORESEED, sin un segundo parámetro o sin un valor de restablecimiento. Para obtener más información, vea DBCC CHECKIDENT (Transact-SQL).

El comportamiento de la función exist() en el tipo de datos XML ha cambiado

El comportamiento de la exist() función ha cambiado al comparar un tipo de datos XML con un valor NULL a 0 (cero). Considere el ejemplo siguiente:

DECLARE @test XML;  
SET @test = null;  
SELECT COUNT(1) WHERE @test.exist('/dogs') = 0;  

En versiones anteriores, esta comparación devuelve 1 (true); ahora, esta comparación devuelve 0 (cero, false).

Las comparaciones siguientes no han cambiado:

DECLARE @test XML;  
SET @test = null;  
SELECT COUNT(1) WHERE @test.exist('/dogs') = 1; -- 0 expected, 0 returned  
SELECT COUNT(1) WHERE @test.exist('/dogs') IS NULL; -- 1 expected, 1 returned  

Véase también

Cambios recientes en las características del Motor de base de datos de SQL Server 2014
Características desusadas del motor de base de datos de SQL Server 2014
Funcionalidad del motor de base de datos no incluida en SQL Server 2014
Nivel de compatibilidad de ALTER DATABASE (Transact-SQL)