Istnieje już otwarty DataReader powiązany z tym poleceniem, który musi być najpierw zamknięty

Możesz użyć metody ToList() przed wyrażeniem return.

var accounts =
from account in context.Accounts
from guranteer in account.Gurantors

 select new AccountsReport
{
    CreditRegistryId = account.CreditRegistryId,
    AccountNumber = account.AccountNo,
    DateOpened = account.DateOpened,
};

 return accounts.AsEnumerable()
               .Select((account, index) => new AccountsReport()
                       {
                           RecordNumber = FormattedRowNumber(account, index + 1),
                           CreditRegistryId = account.CreditRegistryId,
                              DateLastUpdated = DateLastUpdated(account.CreditRegistryId, account.AccountNumber),
                           AccountNumber = FormattedAccountNumber(account.AccountType, account.AccountNumber)}).OrderBy(c=>c.FormattedRecordNumber).ThenByDescending(c => c.StateChangeDate).ToList();


 public DateTime DateLastUpdated(long creditorRegistryId, string accountNo)
    {
        var dateReported = (from h in context.AccountHistory
                            where h.CreditorRegistryId == creditorRegistryId && h.AccountNo == accountNo
                            select h.LastUpdated).Max();
        return dateReported;
    }

Oto działający łańcuch połączeń dla kogoś, kto potrzebuje referencji.

  <connectionStrings>
    <add name="IdentityConnection" connectionString="Data Source=(LocalDb)\v11.0;AttachDbFilename=|DataDirectory|\IdentityDb.mdf;Integrated Security=True;MultipleActiveResultSets=true;" providerName="System.Data.SqlClient" />
  </connectionStrings>

W moim przypadku użycie Include() rozwiązało ten błąd i w zależności od sytuacji może być o wiele bardziej wydajne niż wysyłanie wielu zapytań, gdy można je odpytywać jednocześnie za pomocą join.

IEnumerable<User> users = db.Users.Include("Projects.Tasks.Messages");

foreach (User user in users)
{
    Console.WriteLine(user.Name);
    foreach (Project project in user.Projects)
    {
        Console.WriteLine("\t"+project.Name);
        foreach (Task task in project.Tasks)
        {
            Console.WriteLine("\t\t" + task.Subject);
            foreach (Message message in task.Messages)
            {
                Console.WriteLine("\t\t\t" + message.Text);
            }
        }
    }
}

Użyj składni .ToList(), Aby przekonwertować obiekt odczytany z db na listę, aby uniknąć ponownego odczytu.Mam nadzieję, że to zadziała. Dzięki.

Nie wiem, czy to duplikat, czy nie. Jeśli tak, to przepraszam. Chcę tylko poinformować potrzebujących, jak rozwiązałem mój problem za pomocą ToList().

W moim przypadku mam ten sam wyjątek dla poniższego zapytania.

int id = adjustmentContext.InformationRequestOrderLinks.Where(item => item.OrderNumber == irOrderLinkVO.OrderNumber && item.InformationRequestId == irOrderLinkVO.InformationRequestId).Max(item => item.Id);

Rozwiązałem jak poniżej

List<Entities.InformationRequestOrderLink> links = adjustmentContext.InformationRequestOrderLinks
.Where(item => item.OrderNumber == irOrderLinkVO.OrderNumber && item.InformationRequestId == irOrderLinkVO.InformationRequestId).ToList();

int id = 0;

if (links.Any())
{
  id = links.Max(x => x.Id);
 }
if (id == 0)
{
//do something here
}

Wygląda na to, że wywołujesz DateLastUpdated z aktywnego zapytania przy użyciu tego samego kontekstu EF, a DateLastUpdate wydaje polecenie do samego magazynu danych. Entity Framework obsługuje tylko jedno aktywne polecenie dla każdego kontekstu na raz.

Możesz przekształcić powyższe dwa zapytania w jedno w następujący sposób:

return accounts.AsEnumerable()
        .Select((account, index) => new AccountsReport()
        {
          RecordNumber = FormattedRowNumber(account, index + 1),
          CreditRegistryId = account.CreditRegistryId,
          DateLastUpdated = (
                                                from h in context.AccountHistory 
                                                where h.CreditorRegistryId == creditorRegistryId 
                              && h.AccountNo == accountNo 
                                                select h.LastUpdated).Max(),
          AccountNumber = FormattedAccountNumber(account.AccountType, account.AccountNumber)
        })
        .OrderBy(c=>c.FormattedRecordNumber)
        .ThenByDescending(c => c.StateChangeDate);

Zauważyłem również, że wywołujesz funkcje takie jak FormattedAccountNumber i FormattedRecordNumber w zapytaniach. Chyba, że są to przechowywane procs lub funkcje, które masz zaimportowane z bazy danych do modelu danych podmiotu i zmapowane poprawnie, będą również wyrzucać excepts, ponieważ EF nie będzie wiedział, jak przetłumaczyć te funkcje na instrukcje, które może wysłać do magazynu danych.

Zauważ również, że wywołanie liczby AsEnumerable nie wymusza wykonania zapytania. Dopóki wykonanie zapytania nie zostanie odroczone do momentu wyliczenia. Możesz wymusić wyliczenie z ToList lub ToArray, jeśli chcesz.

Oprócz Ladislav Mrnka ' S Odpowiedź:

Jeśli publikujesz i nadpisujesz kontener na karcie Settings, możesz ustawić MultipleActiveResultSet na True. Możesz znaleźć tę opcję, klikając zaawansowane... i będzie Pod grupą zaawansowaną .

Miałem ten sam błąd, gdy próbowałem zaktualizować niektóre rekordy w pętli odczytu. Wypróbowałem najczęściej głosowaną odpowiedź MultipleActiveResultSets=true i znalazłem, że to tylko obejście, aby uzyskać następny błąd

Nowa transakcja nie jest dozwolona, ponieważ działają inne wątki w sesji

Najlepszym podejściem, które sprawdzi się przy dużych wynikach jest użycie fragmentów i otwarcie osobnego kontekstu dla każdego fragmentu, zgodnie z opisem w  SqlException from Entity Framework-nowa transakcja jest niedozwolone, ponieważ w sesji działają inne wątki

Rozwiązałem ten problem zmieniając wait _accountSessionDataModel.SaveChangesAsync(); na / Align = "center" bgcolor = "# e0ffe0 " / cesarz chin / / align = center / SaveChanges(); w mojej klasie.

 public async Task<Session> CreateSession()
    {
        var session = new Session();

        _accountSessionDataModel.Sessions.Add(session);
        await _accountSessionDataModel.SaveChangesAsync();
     }

Zmienił na:

 public Session CreateSession()
    {
        var session = new Session();

        _accountSessionDataModel.Sessions.Add(session);
        _accountSessionDataModel.SaveChanges();
     }

Problem polegał na tym, że zaktualizowałem sesje w interfejsie po utworzeniu sesji (w kodzie), ale ponieważ SaveChangesAsync dzieje się asynchronicznie, pobieranie sesji spowodowało ten błąd, ponieważ najwyraźniej operacja SaveChangesAsync nie była jeszcze gotowa.

Dla tych, którzy znajdują to przez Google;
Otrzymywałem ten błąd, ponieważ, zgodnie z sugestią błędu, nie udało mi się zamknąć SqlDataReader przed utworzeniem innego na tym samym poleceniu SQL, błędnie zakładając, że będą to śmieci zbierane podczas opuszczania metody, w której został utworzony.

Problem rozwiązałem wywołując sqlDataReader.Close(); przed utworzeniem drugiego czytnika.

W moim przypadku otworzyłem zapytanie z kontekstu danych, jak

    Dim stores = DataContext.Stores _
        .Where(Function(d) filter.Contains(d.code)) _

... a potem zapytałem o to samo...

    Dim stores = DataContext.Stores _
        .Where(Function(d) filter.Contains(d.code)).ToList

Dodanie .ToList do pierwszego rozwiązało mój problem. Myślę, że to ma sens, aby zawinąć to w nieruchomości jak:

Public ReadOnly Property Stores As List(Of Store)
    Get
        If _stores Is Nothing Then
            _stores = DataContext.Stores _
                .Where(Function(d) Filters.Contains(d.code)).ToList
        End If
        Return _stores
    End Get
End Property

Gdzie _stores jest zmienną prywatną, a Filters jest również właściwością readonly, która odczytuje z AppSettings.

Używam web service w moim narzędziu, gdzie te usługi pobierają procedurę składowaną. podczas gdy większa liczba narzędzi klienckich pobiera usługę internetową, pojawia się ten problem. Naprawiłem, określając zsynchronizowany atrybut dla tych funkcji pobiera procedurę składowaną. teraz działa dobrze, błąd nigdy nie pojawił się w moim narzędziu.

 [MethodImpl(MethodImplOptions.Synchronized)]
 public static List<t> MyDBFunction(string parameter1)
  {
  }

Ten atrybut pozwala na przetwarzanie jednego żądania na raz. więc to rozwiązuje problem.

Dla mnie to był mój własny błąd. Próbowałem uruchomić INSERT używając SqlCommand.executeReader(), Kiedy powinienem używać SqlCommand.ExecuteNonQuery(). Został otwarty i nigdy nie zamknięty, powodując błąd. Uważaj na to przeoczenie.

Jest to wyciągnięte ze scenariusza realnego świata:

• kod działa dobrze w środowisku Stage z MultipleActiveResultSets jest ustawiony w łańcuchu połączeń
• kod opublikowany w środowisku produkcyjnym bez MultipleActiveResultSets=true
• tak wiele stron / wywołań działa, gdy jedna zawodzi
[[3]}patrząc bliżej na wezwanie, jest niepotrzebny telefon wykonane do db i wymaga usunięcia
• Set MultipleActiveResultSets = true w produkcji i publikacji kodu wszystko działa dobrze i sprawnie

Podsumowując, nie zapominając o MultipleActiveResultSets, kod mógł działać przez długi czas, zanim odkrył redundantne wywołanie db, które może być bardzo kosztowne, i sugeruję Nie w pełni polegać na ustawieniu atrybutu MultipleActiveResultSets, ale także dowiedz się, dlaczego kod jest potrzebny tam, gdzie się nie powiódł.

Najprawdopodobniej ten problem występuje z powodu "leniwego ładowania" funkcji Entity Framework. Zwykle, o ile nie jest to wyraźnie wymagane podczas wstępnego pobierania, wszystkie połączone DANE (wszystko, co jest przechowywane w innych tabelach bazy danych) są pobierane tylko wtedy, gdy są wymagane. W wielu przypadkach jest to dobra rzecz, ponieważ zapobiega pobieraniu niepotrzebnych danych, a tym samym poprawia wydajność zapytań (brak połączeń) i oszczędza przepustowość.

W sytuacji opisanej w pytaniu wykonuje się pobieranie wstępne, a podczas żądany jest brak fazy" select", wysyłane są dodatkowe zapytania, a następnie EF narzeka na "open DataReader".

Obejście zaproponowane w zaakceptowanej odpowiedzi pozwoli na wykonanie tych zapytań i rzeczywiście całe żądanie zakończy się sukcesem.

Jednakże, jeśli przeanalizujesz żądania wysłane do bazy danych, zauważysz wiele żądań - dodatkowe żądanie dla każdego brakującego (leniwie załadowanego) danych. To może być zabójcze.

A better podejście polega na tym, aby powiedzieć EF, aby wstępnie załadował wszystkie potrzebne leniwe załadowane dane podczas początkowego zapytania. Można to zrobić za pomocą instrukcji "Include":

using System.Data.Entity;

query = query.Include(a => a.LazyLoadedProperty);

W ten sposób zostaną wykonane wszystkie potrzebne połączenia i wszystkie potrzebne dane zostaną zwrócone jako jedno zapytanie. Problem opisany w pytaniu zostanie rozwiązany.