'Intento no válido de leer cuando no hay datos' - la excepción ocurre "a veces" en Entity Framework

Question

A veces aparece el error anterior durante la lectura. La excepción se origina de ASP.NET SqlDataReader cada vez que intenta leer datos antes de llamar al método Read(). Dado que EF hace todo esto internamente, me pregunto qué más puede causar este error. podría ser la conectividad de red (o) db?

gracias

adicional Bounty Información (GenericTypeTea):

Tengo el mismo error después de actualizar el Código de EF Primera RC (4.1):

"no válida intento de leer cuando no hay datos presente "

Este es el código en cuestión:

using (var context = GetContext()) 
{ 
    var query = from item in context.Preferences 
       where item.UserName == userName 
       where item.PrefName == "TreeState" 
       select item; 

    // Error on this line 
    Preference entity = query.FirstOrDefault(); 
    return entity == null ? null : entity.Value; 
} 

La estructura de la tabla es la siguiente:

Preference 
{ 
    Username [varchar(50)] 
    PrefName [varchar(50)] 
    Value [varchar(max)] Nullable 
} 

La tabla es independiente y no tiene relaciones. Este es el código de DbModelBuilder:

private void ConfigurePreference(DbModelBuilder builder) 
{ 
    builder.Entity<Preference>().HasKey(x => new { x.UserName, x.PrefName }); 
    builder.Entity<Preference>().ToTable("RP_Preference"); 
} 

Exactamente el mismo código funciona perfectamente en CTP5. Supongo que esto es un error de RC, pero cualquier idea de cómo solucionarlo sería apreciada.

Answer 1

¿Estás reutilizando contextos? Yo diría que esto está ocurriendo como resultado de algo que está haciendo dentro de GetContext

Si GetContext() proporciona un contexto rancio, en el que se cierra DataReader/dañado, pude ver el suceso anterior.

Answer 2

No puedo reproducir su problema en EF4.1 RC1.

POCO:

public class Preference 
{ 
    public string UserName { get; set; } 
    public string PrefName { get; set; } 
    public string Value { get; set; } 
} 

Contexto:

public class PreferenceContext : DbContext 
{ 
    public DbSet<Preference> Preferences {get;set;} 

    public PreferenceContext() 
    : base("Data Source=localhost;Initial Catalog=_so_question_ef41_rc;Integrated Security=SSPI;") { 
    } 

    protected override void OnModelCreating(DbModelBuilder modelBuilder) 
    { 
     ConfigurePreference(modelBuilder); 
     base.OnModelCreating(modelBuilder); 
    } 

    private void ConfigurePreference(DbModelBuilder builder) 
    { 
     builder.Entity<Preference>().HasKey(x => new { x.UserName, x.PrefName }); 
     builder.Entity<Preference>().ToTable("RP_Preference"); 
    } 
} 

Mi pequeña aplicación de consola:

class Program 
{ 
    static void Main(string[] args) 
    { 
     string userName = "Anon"; 
     for (int i = 0; i < 10000; i++) 
     { 
      var p = GetPreference(userName);     
     } 
    } 

    private static string GetPreference(string userName) 
    { 
     using (var context = new PreferenceContext()) 
     { 
      var query = from item in context.Preferences 
          where item.UserName == userName 
          where item.PrefName == "TreeState" 
          select item; 

      // Error on this line 
      Preference entity = query.FirstOrDefault(); 
      return entity == null ? null : entity.Value; 
     } 
    } 
} 

me lee 10.000, y ningún error. Deberá publicar un código más completo para continuar.

Answer 3

Este error se produce cuando hay una gran cantidad de datos en la versión RC. La diferencia entre RC y CTP5 es que debe especificar la propiedad [MaxLength] que contiene una gran cantidad de datos.

Answer 4

Aumente CommandTimeout en el contexto.

Answer 5

Tuve el mismo problema con EF4 - En mi caso, estaba (tratando de) devolver la lista de entidades dentro de la {} sección de uso.Esto es lo mismo que usted está haciendo en su pregunta:

return entity == null ? null : entity.Value; 

} // fin de utilizar

moví el retorno a después de la} y funcionó.

Creo que tenía el problema debido a que el código estaba en una función que tenían ya consultan la base de datos en otro bloque usando, sospecho que la mesa estaba cerrando pero no informa del error, poniendo fin al uso de bloques antes del retorno lanzado el bloqueo de la base de datos.

Steve