EF 4 produce constantes de cadena UNICODE en SQL donde el tipo de columna es varchar. ¿Como evitar?

En mi código que tienen el siguiente fragmento de una consulta L2E:EF 4 produce constantes de cadena UNICODE en SQL donde el tipo de columna es varchar. ¿Como evitar?

where ol.ordhead.ohcustno == login && (ol.ollastdoctype == "IN") && ol.olstatus == "9"

Esto se traduce en SQL siguiente fragmento:

WHERE ([Extent8].[ohcustno] = @p__linq__1) AND (''IN'' = [Extent7].[ollastdoctype]) AND (''9'' = [Extent7].[olstatus]) ...

En cierta entrada de la consulta se ejecuta 3 segundos. Cómo cambio la consulta de esta manera:

where ol.ordhead.ohcustno == login && (ol.ollastdoctype == "IN" || ol.ollastdoctype == "CR") && ol.olstatus == "9"

y los cambios de SQL resultantes son los siguientes:

WHERE ([Extent6].[ohcustno] = @p__linq__1) AND ([Extent5].[ollastdoctype] IN (N''IN'',N''CR'')) AND (''9'' = [Extent5].[olstatus]) ...

Tenga en cuenta, que por alguna extraña razón Entity Framework decidió convertir mi IN y CR a Unicode. El resultado es que la consulta ahora ejecuta 6 segundos en la misma entrada. Si elimino manualmente el prefijo N de la cláusula IN y vuelvo a ejecutar la consulta en SSMS, el tiempo de ejecución se remonta a 3 segundos. Esto es por supuesto porque SQL Server Query Optimizer no puede obtener ventaja de un índice porque los tipos comparados ahora son diferentes (varchar vs nvarchar)

¿Alguien puede explicarme por qué Entity Framework decide de repente convertir mis constantes en unicode? y como puedo evitarlo?

Fuente

2011-04-29 Andrew Savinykh

Se puede comprobar el modelo de almacenamiento y ver si su columna refleja correctamente varchar tipo nvarchar en lugar de –

@Akash Kava: Esta fue la primera cosa que hice.También tenga en cuenta que no cambié el modelo de almacenamiento, sin embargo, en la primera consulta, EF produce una constante no unicode, y en la segunda consulta, constantes unicode. –

usted puede intentar este método EntityFunction.AsNonUnicode, como sigue

where ol.ordhead.ohcustno == login && 
    (ol.ollastdoctype == EntityFunctions.AsNonUnicode("IN") || 
    ol.ollastdoctype == EntityFunctions.AsNonUnicode("CR")) && 
    ol.olstatus == "9"

Esto sólo es la última esperanza, el próximo informe de error es de Microsoft.

Fuente

2011-04-29 09:00:48

¡Qué sabes! ¡Funcionó! ¡Muchas gracias! –

El EntityFunction.AsNonUnicode solución es en realidad muy limitada, sólo funciona cuando el valor suministrado es o bien un literal o una cadena:

System.NotSupportedException: El método 'System.String AsNonUnicode (System.String) 'solo se admite en LINQ a las Entidades cuando el argumento es una variable de cadena o literal.

Este es un problema grave en EF4.1 y se ha documentado aquí también: http://connect.microsoft.com/VisualStudio/feedback/details/650410/entity-framework-contains-still-defaulting-to-unicode-for-varchar-fields

hasta que se solucione por sí EF, no hay ninguna solución a corto de interceptar la consulta y la sustitución de la mano sintaxis usando algo como EFTraceProvider.

Brutal.

Fuente

2011-08-07 14:44:27 Nariman

Gracias por su comentario –

Esto fue un problema hasta ODP.net versión Beta 2 pero con la versión Beta3 de ODP.net 4.112.2.50 este problema está resuelto.

Fuente

2011-11-25 20:56:28

Este problema se ha resuelto oficialmente en las últimas versiones de EF. Puede definir el tipo de columna usando DataAnnotations. ¡Espero que esto ayude a alguien!

Ver esta respuesta: EF Data Annotations Column Type

Fuente

2013-04-03 20:36:23 norepro

EF 4 produce constantes de cadena UNICODE en SQL donde el tipo de columna es varchar. ¿Como evitar?

Respuesta

Cuestiones relacionadas