Compartir a través de

Problemas conocidos de SqlClient para Entity Framework

En esta sección se describen los problemas conocidos relacionados con el proveedor de datos de .NET Framework para SQL Server (SqlClient).

Espacios finales en funciones de cadena

SQL Server omite los espacios finales en los valores de cadena. Por consiguiente, al pasar espacios finales en una cadena, se pueden producir resultados imprevisibles, incluso errores.

Si ha de tener espacios finales en una cadena, debería considerar anexar un carácter de espacio en blanco al final, para que SQL Server no recorte la cadena. Si no se requieren los espacios finales, se deberían recortar antes de pasarse a la canalización de la consulta.

Función RIGHT

Si se pasa un valor distinto de null como primer argumento y 0 como segundo argumento a RIGHT(nvarchar(max), 0) o RIGHT(varchar(max), 0), se devolverá un valor NULL en lugar de una cadena empty.

Operadores CROSS APPLY y OUTER APPLY

Los operadores CROSS y OUTER APPLY se introdujeron en SQL Server 2005. En algunos casos, la canalización de la consulta podría generar una instrucción de Transact-SQL que contenga los operadores CROSS APPLY y/o OUTER APPLY. Dado que algunos proveedores de back-end, incluidas las versiones de SQL Server anteriores a SQL Server 2005, no admiten estos operadores, estas consultas no se pueden ejecutar en estos proveedores de back-end.

A continuación se muestran algunos escenarios típicos que pueden dar lugar a la presencia de operadores CROSS APPLY o OUTER APPLY en la consulta de salida:

  • Una subconsulta correlacionada con paginación.

  • Un AnyElement sobre una subconsulta correlacionada o sobre una colección generada mediante navegación.

  • Consultas LINQ que usan métodos de agrupación que aceptan un selector de elementos.

  • Una consulta en la que se especifica explícitamente un operador CROSS APPLY u OUTER APPLY

  • Una consulta que tiene una construcción DEREF sobre una construcción REF.

Operador SKIP

Si usa SQL Server 2000, usar SKIP con ORDER BY en columnas que no son de clave podría devolver resultados incorrectos. Es posible omitir más que el número especificado de filas si la columna que no es de clave tiene datos duplicados en ella. Esto se debe a cómo SKIP se traduce para SQL Server 2000. Por ejemplo, en la consulta siguiente, se pueden omitir más de cinco filas si E.NonKeyColumn tiene valores duplicados:

SELECT [E] FROM Container.EntitySet AS [E] ORDER BY [E].[NonKeyColumn] DESC SKIP 5L

Dirigirse a la versión correcta de SQL Server

Entity Framework tiene como destino la consulta de Transact-SQL basada en la versión de SQL Server especificada en el ProviderManifestToken atributo del elemento Schema en el archivo del modelo de almacenamiento (.ssdl). Esta versión puede diferir de la versión de SQL Server real a la que está conectado. Por ejemplo, si usa SQL Server 2005, pero el ProviderManifestToken atributo se establece en 2008, es posible que la consulta de Transact-SQL generada no se ejecute en el servidor. Por ejemplo, una consulta que use los nuevos tipos de fecha y hora que se introdujeron en SQL Server 2008 no se ejecutará en versiones anteriores de SQL Server. Si usa SQL Server 2005, pero el ProviderManifestToken atributo se establece en 2000, la consulta de Transact-SQL generada podría estar menos optimizada o podría obtener una excepción que indique que no se admite la consulta. Para obtener más información, vea la sección Operadores CROSS APPLY y OUTER APPLY, anteriormente en este tema.

Ciertos comportamientos de base de datos dependen del nivel de compatibilidad establecido en la base de datos. Si el ProviderManifestToken atributo se establece en 2005 y la versión de SQL Server es 2005, pero el nivel de compatibilidad de una base de datos se establece en "80" (SQL Server 2000), el Transact-SQL generado tendrá como destino SQL Server 2005, pero podría no ejecutarse según lo previsto debido a la configuración del nivel de compatibilidad. Por ejemplo, puede perder información de ordenación si un nombre de columna de la lista ORDER BY coincide con un nombre de columna en el selector.

Consultas anidadas en proyección

Las consultas anidadas en una cláusula de proyección se podrían traducir en consultas de producto cartesiano en el servidor. En algunos servidores back-end, incluido SQL Server, esto puede hacer que la tabla TempDB sea bastante grande. Esto puede reducir el rendimiento del servidor.

A continuación se muestra un ejemplo de una consulta anidada en una cláusula de proyección:

SELECT c, (SELECT c, (SELECT c FROM AdventureWorksModel.Vendor AS c  ) As Inner2 FROM AdventureWorksModel.JobCandidate AS c  ) As Inner1 FROM AdventureWorksModel.EmployeeDepartmentHistory AS c

Valores de identidad GUID generados por el servidor

Entity Framework admite valores de identidad de tipo GUID generados por el servidor, pero el proveedor debe admitir la devolución del valor de identidad generado por el servidor después de insertar una fila. A partir de SQL Server 2005, puede devolver el tipo GUID generado por el servidor en una base de datos de SQL Server mediante la cláusula OUTPUT.

Consulte también

  • Last updated on