update query framework data consulta linq entity-framework

linq - query - Entidad Framework-"No se puede crear un valor constante de tipo ''Closure type''..." error



sql command entity framework (4)

¿Por qué me sale el error?

No se puede crear un valor constante de tipo ''Tipo de cierre''. Solo los tipos primitivos (por ejemplo Int32, String y Guid) son compatibles en este contexto.

Cuando trato de enumerar la siguiente consulta Linq?

IEnumerable<string> searchList = GetSearchList(); using (HREntities entities = new HREntities()) { var myList = from person in entities.vSearchPeople where upperSearchList.All( (person.FirstName + person.LastName) .Contains).ToList(); }

Actualización : si intento lo siguiente solo para tratar de aislar el problema, aparece el mismo error:

where upperSearchList.All(arg => arg == arg)

Entonces parece que el problema es con el método All, ¿verdad? ¿Alguna sugerencia?


He encontrado la causa del error (estoy usando Framework 4.5). El problema es que EF un tipo complejo, que se pasa en el parámetro "Contiene", no se puede traducir en una consulta SQL. EF puede usar en una consulta SQL solo tipos simples como int, string ...

this.GetAll().Where(p => !assignedFunctions.Contains(p))

GetAll proporciona una lista de objetos con un tipo complejo (por ejemplo: "Función"). Por lo tanto, trataré aquí de recibir una instancia de este tipo complejo en mi consulta SQL, ¡que naturalmente no puede funcionar!

Si puedo extraer de mi lista los parámetros que se adaptan a mi búsqueda, puedo usar:

var idList = assignedFunctions.Select(f => f.FunctionId); this.GetAll().Where(p => !idList.Contains(p.FunktionId))

Ahora EF ya no tiene el tipo complejo "Función" para trabajar, pero por ejemplo, con un tipo simple (largo). ¡Y eso funciona bien!


Me he pasado los últimos 6 meses luchando contra esta limitación con EF 3.5 y aunque no soy la persona más inteligente del mundo, estoy bastante seguro de que tengo algo útil que ofrecer sobre este tema.

El SQL generado al crecer un árbol de 50 millas de expresiones de "estilo OR" resultará en un plan de ejecución de consulta pobre. Estoy lidiando con unos pocos millones de filas y el impacto es sustancial.

Hay un pequeño truco que encontré para hacer un ''en'' SQL que ayuda si solo estás buscando un grupo de entidades por id:

private IEnumerable<Entity1> getByIds(IEnumerable<int> ids) { string idList = string.Join(",", ids.ToList().ConvertAll<string>(id => id.ToString()).ToArray()); return dbContext.Entity1.Where("it.pkIDColumn IN {" + idList + "}"); }

donde pkIDColumn es el nombre de columna de ID de clave principal de su tabla Entity1.

PERO MANTENGA LA LECTURA!

Esto está bien, pero requiere que ya tenga los identificadores de lo que necesito encontrar. A veces solo quiero que mis expresiones lleguen a otras relaciones y lo que sí tengo es un criterio para esas relaciones conectadas.

Si tuviera más tiempo, trataría de representar esto visualmente, pero no solo estudio esta frase por un momento: considere un esquema con las tablas Person, GovernmentId y GovernmentIdType. Andrew Tappert (Person) tiene dos tarjetas de identificación (GovernmentId), una de Oregon (GovernmentIdType) y una de Washington (GovernmentIdType).

Ahora genera un edmx a partir de él.

Ahora imagina que quieres encontrar a todas las personas que tienen un cierto valor de ID, digamos 1234567.

Esto se puede lograr con una sola base de datos acertada con esto:

dbContext context = new dbContext(); string idValue = "1234567"; Expression<Func<Person,bool>> expr = person => person.GovernmentID.Any(gid => gid.gi_value.Contains(idValue)); IEnumerable<Person> people = context.Person.AsQueryable().Where(expr);

¿Ves la subconsulta aquí? El sql generado usará ''uniones'' en lugar de subconsultas, pero el efecto es el mismo. En la actualidad, el servidor SQL optimiza las subconsultas en combinaciones de todas formas, pero de todos modos ...

La clave para este funcionamiento es el. Cualquier dentro de la expresión.


Parece que estás tratando de hacer el equivalente de una condición "DONDE ... EN". Consulte Cómo escribir consultas de estilo ''WHERE IN'' usando LINQ to Entities para ver un ejemplo de cómo hacer ese tipo de consulta con LINQ to Entities.

Además, creo que el mensaje de error es particularmente inútil en este caso porque .Contains no va seguido de paréntesis, lo que hace que el compilador reconozca todo el predicado como una expresión lambda.


Recibí este mensaje de error cuando mi objeto de matriz utilizado en la función .All es nulo Después de inicializar el objeto de matriz, (upperSearchList en su caso), el error se ha ido. El mensaje de error fue engañoso en este caso

donde upperSearchList.All (arg => person.someproperty.StartsWith (arg)))