4060 – Nie można otworzyć bazy danych

Błąd 4060 oznacza, że serwer SQL nie mógł otworzyć wskazanej bazy danych podczas próby połączenia.

4060 – Nie można otworzyć bazy danych: czym jest ten komunikat

Komunikat „4060 – Nie można otworzyć bazy danych” pojawia się w środowisku Microsoft SQL Server, gdy próba nawiązania połączenia wskazuje bazę, do której nie można uzyskać dostępu. Sam numer błędu nie opisuje jednej, zawsze identycznej usterki. Informuje raczej, że etap wyboru lub otwarcia konkretnej bazy danych zakończył się niepowodzeniem. Połączenie z usługą SQL może być możliwe, a mimo to aplikacja nie przejdzie dalej, ponieważ nie zostanie otwarta baza wymagana do pracy programu.

Problem może dotyczyć nazwy bazy, konta użytkownika, stanu samej bazy, konfiguracji połączenia albo sposobu, w jaki aplikacja przekazuje parametry logowania. W praktyce komunikat bywa widoczny podczas uruchamiania programu księgowego, magazynowego, produkcyjnego, rejestracyjnego lub innego systemu korzystającego z relacyjnej bazy danych. Niekiedy pojawia się po zmianie komputera, odtworzeniu kopii zapasowej, aktualizacji aplikacji, zmianie hasła albo przeniesieniu danych na inną instalację.

Warto odróżnić błąd 4060 od sytuacji, w której nie działa cała usługa SQL. Jeżeli usługa jest zatrzymana, aplikacja może zgłaszać dodatkowe komunikaty o braku połączenia lub niedostępności instancji. Przy błędzie 4060 połączenie często dochodzi do określonego etapu, lecz wskazana baza nie może zostać otwarta dla danego użytkownika lub w danym stanie technicznym.

4060 i kontekst techniczny: nazwa bazy, instancja oraz uprawnienia

Jedną z najczęstszych przyczyn jest nieprawidłowa nazwa bazy danych wpisana w konfiguracji aplikacji. Literówka, zmiana wielkości liter w środowisku o wrażliwej kolacji, użycie nazwy starej bazy albo wskazanie innej instancji może spowodować, że program próbuje otworzyć obiekt, którego nie znajduje. Z tego powodu należy porównać ustawienia aplikacji z rzeczywistą nazwą bazy widoczną w narzędziu administracyjnym SQL.

Znaczenie ma również sposób wskazywania instancji. Instalacja domyślna i instalacja nazwana mogą wymagać innego zapisu w polu serwera. Aplikacja może łączyć się z właściwym komputerem, ale z niewłaściwą instancją usługi. W takim przypadku baza istniejąca w jednej instancji nie będzie dostępna w drugiej. Podobny skutek może wystąpić po zmianie nazwy komputera, odtworzeniu konfiguracji sieciowej lub ponownym zainstalowaniu programu.

Drugim ważnym obszarem są uprawnienia. Konto używane przez aplikację musi mieć możliwość zalogowania się oraz dostęp do wskazanej bazy. Oddzielnie należy rozpatrywać uwierzytelnianie Windows i uwierzytelnianie SQL. Użytkownik może poprawnie wpisywać hasło, a mimo to nie mieć przypisania do konkretnej bazy. Może też istnieć login, lecz brakować odpowiadającego mu użytkownika wewnątrz bazy. Taki stan często pojawia się po przeniesieniu bazy na inną instalację, ponieważ identyfikator loginu i użytkownika bazy może wymagać ponownego powiązania.

Przydatne jest porównanie kilku sytuacji. Jeżeli administrator może otworzyć bazę, a aplikacja nie, należy skupić się na koncie i parametrach programu. Jeżeli nie może jej otworzyć nikt, trzeba sprawdzić stan bazy, dostępność plików oraz logi. Jeżeli działa połączenie do bazy systemowej, ale nie do konkretnej bazy użytkowej, problem jest prawdopodobnie związany z nazwą, stanem lub uprawnieniami tej jednej bazy.

4060 – typowe problemy prowadzące do odmowy otwarcia bazy

Przy diagnozie warto uwzględnić historię zdarzeń, ponieważ moment wystąpienia komunikatu często zawęża przyczynę. Po zmianie hasła może zostać używane stare hasło zapisane w aplikacji. Po aktualizacji programu może zmienić się format konfiguracji albo domyślna nazwa bazy. Po odtworzeniu kopii zapasowej baza może być dostępna pod inną nazwą, znajdować się w stanie przywracania albo nie mieć przypisanych tych samych użytkowników co wcześniej.

Jednym z problemów jest baza oznaczona jako niedostępna, w trybie tylko do odczytu, w trakcie przywracania lub oczekująca na odzyskanie. W zależności od stanu i sposobu połączenia aplikacja może wtedy otrzymać właśnie błąd dotyczący niemożności otwarcia bazy. Należy także sprawdzić, czy pliki bazy znajdują się w oczekiwanej lokalizacji oraz czy konto usługi ma dostęp do folderu, w którym są przechowywane. Sam dostęp administratora systemu operacyjnego nie zawsze oznacza dostęp konta używanego przez usługę SQL.

W środowisku sieciowym znaczenie może mieć rozwiązywanie nazwy komputera, reguła zapory, dostępność portu oraz poprawna komunikacja z właściwą instancją. Jeżeli aplikacja działa tylko na jednym stanowisku, a z innych komputerów pojawia się 4060, trzeba porównać konfigurację połączenia, zapis nazwy hosta i sposób uwierzytelniania. Jeśli błąd występuje na wszystkich stanowiskach po jednej zmianie, większe prawdopodobieństwo dotyczy samej bazy, konta lub usługi.

Nie należy pochopnie tworzyć nowej bazy o tej samej nazwie. Taki krok może ukryć właściwą przyczynę i zwiększyć ryzyko pomylenia pustej bazy z bazą zawierającą dane. Przed jakąkolwiek zmianą powinno się ustalić, która baza jest właściwa, kiedy ostatnio działała, gdzie znajduje się kopia zapasowa oraz czy dane aplikacji mają znaczenie dla bieżącej pracy.

4060 – praktyczne wskazówki bez ryzyka utraty danych

Prace warto rozpocząć od zebrania pełnego komunikatu, nazwy aplikacji, nazwy instancji, nazwy bazy oraz informacji o tym, czy problem dotyczy jednego, czy wszystkich stanowisk. Pomocne jest zapisanie chwili wystąpienia błędu i ostatniej wykonanej zmiany. Takie dane pozwalają połączyć komunikat z aktualizacją, migracją, zmianą hasła, przywróceniem kopii lub modyfikacją sieci.

Następnie można sprawdzić, czy usługa SQL jest uruchomiona, czy wskazana baza jest widoczna w narzędziu administracyjnym i czy nie ma statusu sugerującego przywracanie albo odzyskiwanie. Jeżeli dostęp administracyjny jest możliwy, należy zweryfikować, czy konto używane przez aplikację istnieje, czy hasło jest aktualne i czy konto ma użytkownika przypisanego do właściwej bazy. Warto zachować ostrożność przy zmianie uprawnień, ponieważ nadanie zbyt szerokiego dostępu może naruszyć zasady bezpieczeństwa.

Przydatne bywają logi SQL oraz logi aplikacji. Mogą wskazać dokładną nazwę bazy, konto, z którego korzysta program, oraz dodatkowy kod opisujący przyczynę odmowy. Sam komunikat z okna aplikacji bywa skrócony i nie pokazuje pełnego kontekstu. Jeżeli baza jest ważna, przed naprawą powinno się wykonać sprawdzoną kopię zapasową, o ile jej utworzenie nie pogorszy stanu systemu. Nie powinno się usuwać plików bazy, zmieniać ich nazw ani odłączać bazy bez zrozumienia skutków.

Gdy problem dotyczy tylko jednego programu, należy sprawdzić jego plik konfiguracyjny, sposób przechowywania danych logowania oraz ustawienia połączenia. Czasami aplikacja korzysta z innego konta niż zakładano albo przechowuje nieaktualną nazwę bazy. Gdy połączenie jest wykonywane przez usługę systemową, istotne jest konto tej usługi, a nie konto aktualnie zalogowanej osoby.

4060 – kiedy zgłosić się do serwisu komputerowego

Do serwisu warto zgłosić się wtedy, gdy błąd zatrzymuje pracę programu, dotyczy danych firmowych albo pojawił się po awarii dysku, nagłym wyłączeniu komputera, przenosinach danych lub nieudanej aktualizacji. Szczególnej ostrożności wymaga sytuacja, w której nie wiadomo, gdzie znajduje się aktualna kopia zapasowa, baza jest widoczna jako niedostępna albo próby naprawy powodują kolejne komunikaty. Samodzielne kasowanie plików, instalowanie kolejnych wersji oprogramowania i wielokrotne odtwarzanie kopii może utrudnić późniejsze odzyskanie spójnego stanu.

W ramach zgłoszenia przydatne będzie przekazanie treści komunikatu, zrzutu ekranu, nazwy używanej aplikacji, informacji o ostatniej działającej konfiguracji oraz danych o wykonanych zmianach. Nie powinno się przesyłać haseł w treści wiadomości. Można natomiast przygotować opis konta, sposobu logowania i zakresu problemu, aby możliwe było bezpieczne zaplanowanie czynności.

W Warszawie takie przypadki można przekazać do Warszawskiego Pogotowia Komputerowego 24/7 pod numerem +48 22 100 48 29. Przy zgłoszeniu należy opisać, czy błąd 4060 występuje lokalnie, czy w całej sieci, oraz czy dostęp do innych baz lub programów pozostaje możliwy. Pozwala to rozpocząć od rozróżnienia problemu z konfiguracją aplikacji, kontem użytkownika, usługą SQL, dostępem do plików i stanem bazy. Po ustaleniu przyczyny można dobrać działania ograniczające ryzyko dla danych i przywrócić poprawne uruchamianie programu.