Una consulta de búsqueda devolvió este error. Lo siento porque la cláusula in es descomunal en un objeto subordinado, cuando intento ORM el otro objeto.Se proporcionaron demasiados parámetros en esta solicitud de RPC. El máximo es 2100.?
Aparentemente en las cláusulas no debe construirse 1 parámetro a la vez. Gracias ibatis.
Su mejor opción es revisar su aplicación para pasar menos de 2100 parámetros al procedimiento almacenado. Este es un DBMS limit that can't be raised.
Usted puede hacer algunas cosas:
No es tan extraño ... an in (@ p1, @ p2, ..., @ p2101) generado por un OR/M – JeremyWeir
Enlace agregado al uso de ejemplo de # 1 –
Si está pasando 2100 parámetros a un solo procedimiento almacenado, simplemente está haciendo algo mal. No aumente el límite ni trate de evitar esta abominación, descubra cómo hacer las cosas bien.
-1 Si tengo más de 2100 filas para eliminar (Por PK Id) ¿cómo es eso una abominación? Tengo un sistema altamente transaccional que empuja las filas a razón de 400 por minuto. Si las cosas caen por más de unos pocos minutos, mi proceso de purga tendrá más de 2100 filas que necesitan limpieza (y no puedo limpiarlo en base a otra cosa que no sea el Id de la fila). – Vaccano
@Vaccano: primero, no soy seguidor de Linq (u otros ORM relacionados). En parte, es porque el intento de proteger a los desarrolladores de SQL lleva a "abominaciones" como la que surgió aquí.DevelopingChris no * creó * un sproc con tantos params, su ORM lo hizo. En segundo lugar, hay muchas maneras de abordar un problema como el suyo sin siquiera pensar en trabajar a través de un procedimiento almacenado con más de 2100 parámetros. Como dije, si su mente salta a un parámetro de 2100+, procedimiento almacenado construido dinámicamente como una solución, entonces realmente necesita pensar de nuevo. Claramente, hay mejores soluciones. –
Comentando una publicación anterior, pero me encontré con el problema también. Usando Dapper.NET para encontrar los identificadores de ítems que están inactivos (~ 8000 de un conjunto original de ~ 30000). Luego, pasar esa lista a una sección "where id not in()". Bombardeó en este punto con el mismo mensaje de error. Sin procedimiento almacenado. Y de ninguna manera Dapper.NET me protege del SQL. La consulta está ahí. Dicho esto, me "arreglé" tirando de todos los artículos, y luego haciendo una declaración LINQ de .Where (c =>! InactIds.Contains (c.Id)). ¿Podría simplemente haber puesto la declaración de inactivos en el lugar? Claro, pero diferente clase de elemento, diferentes criterios – Robert
Tengo el mismo error cuando uso una consulta aparentemente inocente de LINQ a SQL. Sólo quería recuperar todos los registros cuyas ID estaban entre los que están almacenados en un array:
dataContext.MyTable.Where(item => ids.Contains(item.Id)).ToArray();
Resultó que la matriz ids tenía más de 2100 artículos, y parece que el DataContext añade un parámetro para cada elemento en la matriz en la consulta SQL resultante.
Al final fue un error en mi código, ya que la matriz de IDS no tenía que tener tantos elementos. Pero, de todos modos, vale la pena tener en cuenta que se necesita una validación adicional cuando se utilizan dichos constructos en LINQ to SQL.
gracias por validar la pregunta, me encantaría que lo votaras, ya que te topaste con esto y será claramente útil para otros que permanezca en el historial de búsqueda del mundo. – DevelopingChris
El mismo problema me mordió. ¿Alguna sugerencia para una solución elegante? –
¡No importa! encontró una respuesta aquí en StackOverflow: http://stackoverflow.com/questions/656167/hitting-the-2100-parameter-limit-sql-server-when-using-contains –
Vas a tener que publicar algo de contexto. Su pregunta transmite poco o ningún significado (ni tampoco su gran línea de asunto). –
El título es demasiado corto – Dan
wow! ¡Nunca supe que podrías pasar 2100 parámetros en el procedimiento! –