Entity Framework: ya hay un DataReader abierto asociado con este comando

Estoy usando Entity Framework y ocasionalmente obtendré este error.

EntityCommandExecutionException
{"There is already an open DataReader associated with this Command which must be closed first."}
   at System.Data.EntityClient.EntityCommandDefinition.ExecuteStoreCommands...

Aunque no estoy haciendo ninguna gestión de conexión manual.

Este error ocurre de forma intermitente.

código que desencadena el error (acortado para facilitar la lectura):

        if (critera.FromDate > x) {
            t= _tEntitites.T.Where(predicate).ToList();
        }
        else {
            t= new List<T>(_tEntitites.TA.Where(historicPredicate).ToList());
        }

usando el patrón Dispose para abrir una nueva conexión cada vez.

using (_tEntitites = new TEntities(GetEntityConnection())) {

    if (critera.FromDate > x) {
        t= _tEntitites.T.Where(predicate).ToList();
    }
    else {
        t= new List<T>(_tEntitites.TA.Where(historicPredicate).ToList());
    }

}

sigue siendo problemático

¿Por qué EF no reutilizaría una conexión si ya está abierta?

No se trata de cerrar la conexión. EF gestiona la conexión correctamente. Comprendo que este problema es que hay múltiples comandos de recuperación de datos ejecutados en una sola conexión (o un solo comando con múltiples selecciones) mientras que el siguiente DataReader se ejecuta antes de que el primero haya completado la lectura. La única forma de evitar la excepción es permitir múltiples DataReaders anidados = activar MultipleActiveResultSets. Otro escenario cuando esto sucede siempre es cuando itera a través del resultado de la consulta (IQueryable) y activará una carga diferida para la entidad cargada dentro de la iteración.

Como alternativa al uso de MARS (MultipleActiveResultSets) puede escribir su código para no abrir múltiples conjuntos de resultados.

Lo que puede hacer es recuperar los datos en la memoria, de esa manera no tendrá el lector abierto. A menudo se debe a la iteración a través de un conjunto de resultados al intentar abrir otro conjunto de resultados.

Código de muestra:

public class MyContext : DbContext
{
    public DbSet<Blog> Blogs { get; set; }
    public DbSet<Post> Posts { get; set; }
}

public class Blog
{
    public int BlogID { get; set; }
    public virtual ICollection<Post> Posts { get; set; }
}

public class Post
{
    public int PostID { get; set; }
    public virtual Blog Blog { get; set; }
    public string Text { get; set; }
}

Digamos que está haciendo una búsqueda en su base de datos que contiene estos:

var context = new MyContext();

//here we have one resultset
var largeBlogs = context.Blogs.Where(b => b.Posts.Count > 5); 

foreach (var blog in largeBlogs) //we use the result set here
{
     //here we try to get another result set while we are still reading the above set.
    var postsWithImportantText = blog.Posts.Where(p=>p.Text.Contains("Important Text"));
}

Podemos hacer una solución simple a esto agregando .ToList () de esta manera:

var largeBlogs = context.Blogs.Where(b => b.Posts.Count > 5).ToList();

Esto obliga al marco de la entidad a cargar la lista en la memoria, por lo tanto, cuando lo iteramos en el bucle foreach ya no está usando el lector de datos para abrir la lista, sino que está en la memoria.

Me doy cuenta de que esto podría no ser deseable si desea cargar algunas propiedades de forma diferida, por ejemplo. Este es principalmente un ejemplo que, con suerte, explica cómo / por qué podría tener este problema, para que pueda tomar decisiones en consecuencia

Hay otra forma de superar este problema. Si es una mejor manera depende de su situación.

El problema resulta de la carga diferida, por lo que una forma de evitarlo es no tener una carga diferida, mediante el uso de Incluir:

var results = myContext.Customers
    .Include(x => x.Orders)
    .Include(x => x.Addresses)
    .Include(x => x.PaymentMethods);

Si usa los Includes apropiados , puede evitar habilitar MARS. Pero si pierde uno, obtendrá el error, por lo que habilitar MARS es probablemente la forma más fácil de solucionarlo.

Obtiene este error, cuando la colección que está intentando iterar es una carga lenta (IQueriable).

foreach (var user in _dbContext.Users)
{    
}

La conversión de la colección IQueriable en otra colección enumerable resolverá este problema. ejemplo

_dbContext.Users.ToList()

Nota: .ToList () crea un nuevo conjunto cada vez y puede causar problemas de rendimiento si se trata de datos de gran tamaño.

Resolví el problema fácilmente (pragmático) agregando la opción al constructor. Por lo tanto, lo uso solo cuando es necesario.

public class Something : DbContext
{
    public Something(bool MultipleActiveResultSets = false)
    {
        this.Database
            .Connection
            .ConnectionString = Shared.ConnectionString /* your connection string */
                              + (MultipleActiveResultSets ? ";MultipleActiveResultSets=true;" : "");
    }
...

Intente en su cadena de conexión para establecer MultipleActiveResultSets=true. Esto permite la multitarea en la base de datos.

Server=yourserver ;AttachDbFilename=database;User Id=sa;Password=blah ;MultipleActiveResultSets=true;App=EntityFramework

Eso funciona para mí ... ya sea que su conexión en app.config o la configuró mediante programación ... espero que esto sea útil

Originalmente había decidido usar un campo estático en mi clase API para hacer referencia a una instancia del objeto MyDataContext (donde MyDataContext es un objeto de contexto EF5), pero eso es lo que parece crear el problema. Agregué código como el siguiente a cada uno de mis métodos API y eso solucionó el problema.

using(MyDBContext db = new MyDBContext())
{
    //Do some linq queries
}

Como han dicho otras personas, los objetos de contexto de datos de EF NO son seguros para subprocesos. Por lo tanto, colocarlos en el objeto estático eventualmente causará el error "lector de datos" en las condiciones adecuadas.

Mi suposición original era que crear solo una instancia del objeto sería más eficiente y permitiría una mejor gestión de la memoria. Por lo que he reunido investigando este tema, ese no es el caso. De hecho, parece ser más eficiente tratar cada llamada a su API como un evento aislado y seguro para subprocesos. Asegurarse de que todos los recursos se liberen correctamente, ya que el objeto queda fuera de alcance.

Esto tiene sentido especialmente si lleva su API a la siguiente progresión natural, que sería exponerla como un WebService o REST API.

Divulgar

• SO: Windows Server 2012
• .NET: instalado 4.5, proyecto usando 4.0
• Fuente de datos: MySQL
• Marco de aplicación: MVC3
• Autenticación: formularios

Noté que este error ocurre cuando envío un IQueriable a la vista y lo uso en un foreach doble, donde el foreach interno también necesita usar la conexión. Ejemplo simple (ViewBag.parents puede ser IQueriable o DbSet):

foreach (var parent in ViewBag.parents)
{
    foreach (var child in parent.childs)
    {

    }
}

La solución simple es usar .ToList()en la colección antes de usarla. También tenga en cuenta que MARS no funciona con MySQL.

Descubrí que tenía el mismo error, y ocurrió cuando estaba usando un en Func<TEntity, bool>lugar de un Expression<Func<TEntity, bool>>para su predicate.

Una vez que cambié todo Func'sa Expression'sla excepción, dejé de ser arrojado.

Creo que EntityFramworkhace algunas cosas inteligentes con Expression'slas que simplemente no haceFunc's

2 soluciones para mitigar este problema:

1. Fuerce el almacenamiento en caché de memoria manteniendo la carga lenta .ToList() después de su consulta, para que pueda iterar abriendo un nuevo DataReader.
2. .Include(/ entidades adicionales que desea cargar en la consulta /) esto se llama carga ansiosa, que le permite (de hecho) incluir objetos asociados (entidades) durante la ejecución de una consulta con el DataReader.

Un buen punto intermedio entre habilitar MARS y recuperar todo el conjunto de resultados en la memoria es recuperar solo ID en una consulta inicial y luego recorrer las ID que materializan cada entidad a medida que avanza.

Por ejemplo (usando las entidades de muestra "Blog y publicaciones" como en esta respuesta ):

using (var context = new BlogContext())
{
    // Get the IDs of all the items to loop through. This is
    // materialized so that the data reader is closed by the
    // time we're looping through the list.
    var blogIds = context.Blogs.Select(blog => blog.Id).ToList();

    // This query represents all our items in their full glory,
    // but, items are only materialized one at a time as we
    // loop through them.
    var blogs =
        blogIds.Select(id => context.Blogs.First(blog => blog.Id == id));

    foreach (var blog in blogs)
    {
        this.DoSomethingWith(blog.Posts);

        context.SaveChanges();
    }
}

Hacer esto significa que solo extrae unos pocos miles de enteros en la memoria, en lugar de miles de gráficos de objetos completos, lo que debería minimizar el uso de la memoria al tiempo que le permite trabajar elemento por elemento sin habilitar MARS.

Otro buen beneficio de esto, como se ve en la muestra, es que puede guardar los cambios a medida que recorre cada elemento, en lugar de tener que esperar hasta el final del ciclo (o alguna otra solución similar), como sería necesario incluso con MARS habilitado (ver aquí y aquí ).

En mi caso, descubrí que faltaban declaraciones de "espera" antes de las llamadas myContext.SaveChangesAsync (). Agregar esperar antes de esas llamadas asíncronas solucionó los problemas del lector de datos para mí.

Si intentamos agrupar parte de nuestras condiciones en un Func <> o método de extensión, obtendremos este error, supongamos que tenemos un código como este:

public static Func<PriceList, bool> IsCurrent()
{
  return p => (p.ValidFrom == null || p.ValidFrom <= DateTime.Now) &&
              (p.ValidTo == null || p.ValidTo >= DateTime.Now);
}

Or

public static IEnumerable<PriceList> IsCurrent(this IEnumerable<PriceList> prices) { .... }

Esto arrojará la excepción si intentamos usarlo en un Where (), lo que deberíamos hacer en su lugar es construir un predicado como este:

public static Expression<Func<PriceList, bool>> IsCurrent()
{
    return p => (p.ValidFrom == null || p.ValidFrom <= DateTime.Now) &&
                (p.ValidTo == null || p.ValidTo >= DateTime.Now);
}

Se puede leer más en: http://www.albahari.com/nutshell/predicatebuilder.aspx

Este problema se puede resolver simplemente convirtiendo los datos en una lista

 var details = _webcontext.products.ToList();


            if (details != null)
            {
                Parallel.ForEach(details, x =>
                {
                    Products obj = new Products();
                    obj.slno = x.slno;
                    obj.ProductName = x.ProductName;
                    obj.Price = Convert.ToInt32(x.Price);
                    li.Add(obj);

                });
                return li;
            }

En mi situación, el problema ocurrió debido a un registro de inyección de dependencia. Estaba inyectando un servicio de alcance por solicitud que estaba usando un dbcontext en un servicio registrado singleton. Por lo tanto, el dbcontext se utilizó dentro de múltiples solicitudes y, por lo tanto, el error.

En mi caso, el problema no tenía nada que ver con la cadena de conexión MARS sino con la serialización json. Después de actualizar mi proyecto de NetCore2 a 3, recibí este error.

Más información se puede encontrar aquí

Resolví este problema usando la siguiente sección de código antes de la segunda consulta:

 ...first query
 while (_dbContext.Connection.State != System.Data.ConnectionState.Closed)
 {
     System.Threading.Thread.Sleep(500);
 }
 ...second query

puedes cambiar el tiempo de sueño en milisegundos

PD útil cuando se usan hilos