Subiekt nie łączy się z serwerem SQL – co sprawdzić krok po kroku

Rano włączasz komputer, uruchamiasz Subiekta i zamiast listy firm widzisz komunikat, że nie można połączyć się z serwerem. Na komputerze, na którym stoi baza, program działa, a na pozostałych stanowiskach już nie. To jeden z najczęstszych problemów w Subiekcie nexo i Subiekcie GT. Na szczęście zwykle da się go rozwiązać w kilkanaście minut. Poniżej kolejność, w jakiej sprawdzam to u klientów.

Skąd się bierze ten błąd

Subiekt nexo i Subiekt GT trzymają dane w bazie Microsoft SQL Server. Na jednym komputerze (serwerze) działa usługa SQL, a pozostałe stanowiska łączą się z nią przez sieć. Gdy którykolwiek element tego łańcucha zawiedzie, program nie może się połączyć: usługa SQL nie działa, komputery się nie widzą, zapora blokuje ruch albo zmienił się adres serwera.

Krok 1. Czy serwer w ogóle jest włączony?

Brzmi banalnie, ale to najczęstsza przyczyna. Komputer z bazą mógł się zrestartować po aktualizacji Windows i czekać na ekranie logowania, przejść w uśpienie albo zostać wyłączony na noc. Upewnij się, że działa i nie jest uśpiony. Na komputerze pełniącym rolę serwera warto wyłączyć usypianie w opcjach zasilania.

Krok 2. Czy działa usługa SQL Server?

Na serwerze otwórz Usługi (wpisz „usługi” w menu Start) i znajdź pozycję SQL Server (nazwa instancji). Przy standardowej instalacji z instalatora InsERT instancja ma zwykle nazwę INSERTNEXO dla nexo albo INSERTGT dla GT. Stan powinien być „Uruchomiona”, a typ uruchomienia „Automatyczny”. Jeśli usługa jest zatrzymana, uruchom ją. Jeśli od razu się zatrzymuje, przyczyna jest poważniejsza (np. uszkodzona baza lub brak miejsca na dysku) i warto skontaktować się z serwisem.

Przy okazji sprawdź też usługę SQL Server Browser. Pomaga stanowiskom znaleźć instancję o nazwie, więc gdy jest wyłączona, połączenie po nazwie instancji często nie działa.

Krok 3. Czy komputery się widzą w sieci?

Na stanowisku, które nie może się połączyć, otwórz wiersz poleceń i wpisz ping nazwa-serwera, a potem ping adres-IP-serwera. Jeśli ping po adresie IP działa, a po nazwie nie, problem leży w rozwiązywaniu nazw. Wtedy pomaga wpisanie w konfiguracji połączenia adresu IP zamiast nazwy. Jeśli nie działa żaden, sprawdź kabel, Wi-Fi, przełącznik i to, czy oba komputery są w tej samej sieci.

Krok 4. Czy serwer nie zmienił adresu IP?

Router przydziela adresy automatycznie i po restarcie może dać serwerowi inny adres. Jeśli stanowiska łączą się po adresie IP, nagle trafiają w próżnię. Rozwiązanie na stałe to stały adres IP dla serwera, najlepiej jako rezerwacja w routerze.

Krok 5. Czy zapora Windows nie blokuje połączenia?

Po dużej aktualizacji Windows albo instalacji programu antywirusowego reguły zapory potrafią się zmienić. Na serwerze trzeba zezwolić na ruch do programu SQL Server (sqlservr.exe) oraz do SQL Server Browser (port UDP 1434). Gdy instancja działa na stałym porcie TCP, trzeba otworzyć również ten port. Uwaga też na profil sieci: jeśli Windows uznał sieć firmową za „publiczną”, blokuje znacznie więcej. Zmień ją na „prywatną”.

Krok 6. Czy SQL Server przyjmuje połączenia przez sieć?

W SQL Server Configuration Manager na serwerze sprawdź, czy protokół TCP/IP jest włączony dla instancji Subiekta. Po zmianie ustawień trzeba zrestartować usługę SQL Server.

Krok 7. Czy stanowisko ma dobre dane połączenia?

Jeśli serwer był przenoszony na inny komputer albo zmieniła się jego nazwa, stanowiska mogą wciąż szukać starego. Sprawdź w konfiguracji połączenia programu, na jaki serwer i instancję wskazuje stanowisko, i popraw na właściwe.

Kiedy lepiej nie działać samemu

Jeśli usługa SQL nie chce się uruchomić, w dzienniku zdarzeń pojawiają się błędy bazy albo na dysku serwera brakuje miejsca, nie kombinuj z plikami bazy. Nieumiejętne działania mogą skończyć się utratą danych. Najpierw zrób kopię całego folderu z danymi SQL, a potem zadzwoń do serwisu.

Jak zapobiec temu na przyszłość

• Stały adres IP serwera.
• Wyłączone usypianie i kontrolowane restarty po aktualizacjach.
• Uporządkowane reguły zapory i sieć ustawiona jako prywatna.
• Regularna, sprawdzona kopia zapasowa bazy.

Nie chcesz tego robić samemu?

Połączę się zdalnie i zwykle rozwiążę problem jeszcze tego samego dnia. W Mińsku Mazowieckim i Warszawie mogę też przyjechać na miejsce. Zadzwoń: +48 579 978 211 albo zobacz naprawę baz danych SQL i stałą opiekę serwisową.