Mamy kod klienta, który używa klasy SqlConnection w .NET do rozmowy z bazą danych SQLServer. Ten błąd powoduje okresowe awarie:

„ExecuteReader wymaga otwartego i dostępnego połączenia. Aktualny stan połączenia jest zamknięty”

„Tymczasowym” rozwiązaniem jest ponowne uruchomienie procesu, po czym wszystko działa - jednak jest to oczywiście niezadowalające.

Kod utrzymuje pamięć podręczną instancji SqlConnection, po jednej dla każdej bazy danych.

Chcielibyśmy ponownie napisać kod, ale zanim to zrobię, muszę wiedzieć kilka rzeczy:

Moje pierwsze pytanie brzmi: czy wielokrotne łączenie i rozłączanie obiektów SqlConnection jest nieefektywne, czy też biblioteka bazowa wykonuje w naszym imieniu zestawianie połączeń?

// Is this bad/inefficient?
for(many-times)
{
    using(SQLConnection conn = new SQLConnection(connectionString))
    {
        // do stuff with conn
    }
}

Ponieważ nasz kod manie wykonaj powyższe, co wydaje się prawdopodobną przyczyną problemu, że coś dzieje się z bazową bazą danych SQLServer podczas „czasu życia” połączenia, które powoduje zamknięcie połączenia ...

Jeśli okaże się, że warto „buforować” obiekty SqlConnection, jest to zalecany sposób obsługi wszystkich błędów, które można rozwiązać po prostu przez „ponowne połączenie” z bazą danych. Mówię o scenariuszach takich jak:

Baza danych jest przenoszona w tryb offline i przywracana do trybu online, ale proces klienta nie miał otwartych transakcji, gdy tak się działoBaza danych została „odłączona”, a następnie „ponownie połączona”

Zauważam, że w SqlConnection istnieje właściwość „State” ... czy istnieje odpowiedni sposób na zapytanie?

Na koniec mam testową instancję SQLServer skonfigurowaną z pełnymi prawami dostępu: jak mogę przejść do odtworzenia dokładnego błędu „ExecuteReader wymaga otwartego i dostępnego połączenia. Aktualny stan połączenia jest zamknięty”