Błędy połączenia Subiekta GT z SQL Server

Gdy Subiekt GT nie może połączyć się z bazą

Brak połączenia Subiekta GT z SQL Server zwykle pojawia się podczas uruchamiania programu, wyboru podmiotu albo wykonywania operacji na danych. Komunikat może informować o niedostępnym serwerze, nieudanym logowaniu, błędzie sieci lub braku wskazanej bazy. Sam komunikat nie zawsze wskazuje dokładną przyczynę, dlatego diagnozę prowadzi się od elementów lokalnych do sieciowych.

Najpierw ustala się, czy problem dotyczy jednego stanowiska, wszystkich komputerów, jednego podmiotu czy całej instancji SQL Server. Instancja SQL Server, czyli konkretna usługa obsługująca bazy danych, może działać poprawnie dla jednej aplikacji, a jednocześnie być niedostępna dla Subiekta GT z powodu błędnego adresu lub konta. Ważne jest także rozróżnienie awarii połączenia od uszkodzenia danych. Program może nie widzieć bazy, mimo że sama baza pozostaje prawidłowa.

Najczęstsze przyczyny komunikatu o braku serwera

Najczęściej problem wynika z zatrzymanej usługi SQL Server, zmienionej nazwy komputera albo nieprawidłowego adresu serwera zapisanego w konfiguracji. Po aktualizacji systemu Windows, restarcie komputera lub zmianie ustawień sieci usługa może nie uruchomić się automatycznie. W środowisku z kilkoma stanowiskami przyczyną bywa również utrata dostępu do komputera, na którym przechowywana jest baza.

Inny wariant to błędna nazwa instancji. SQL Server może działać jako instancja domyślna albo nazwana, na przykład w formie nazwa-komputera\instancja. Jeśli w Subiekcie GT wpisano inną nazwę, program nie znajdzie właściwego miejsca. Podobny efekt powoduje wpisanie starego adresu IP, czyli numeru identyfikującego urządzenie w sieci.

Możliwy jest też problem z portem. Port, czyli logiczny kanał komunikacji używany przez usługę sieciową, może być zablokowany przez zaporę albo niedostępny po zmianie konfiguracji. Wtedy serwer działa, lecz stanowisko z Subiektem GT nie może nawiązać połączenia.

Błąd logowania a brak dostępu do serwera

Błąd logowania oznacza inną sytuację niż komunikat o niedostępnym serwerze. Serwer został odnaleziony, ale nie zaakceptował danych konta. SQL Server korzysta z uwierzytelniania, czyli mechanizmu sprawdzającego, czy podane konto i hasło mają prawo wejść do systemu. W zależności od konfiguracji może być używane uwierzytelnianie Windows albo konto SQL Server.

Przyczyną może być zmienione hasło, zablokowane konto, wyłączony tryb logowania SQL Server lub brak uprawnień do konkretnej bazy. Uprawnienia, czyli zakres operacji dozwolonych dla konta, mogą obejmować samo połączenie z serwerem, ale nie dostęp do wybranego podmiotu. Nie należy pochopnie tworzyć nowego konta ani zmieniać uprawnień administratora. Takie działania mogą utrudnić późniejsze ustalenie, co było przyczyną problemu.

Jeśli błąd pojawia się tylko na jednym stanowisku, sprawdzana jest konfiguracja tego komputera. Jeżeli nie działa logowanie na wszystkich stanowiskach, analizuje się konto, usługę SQL Server i dostęp do serwera. W każdym przypadku przed zmianami w bazie wykonywana jest jej kopia.

Plik gt.ini i zapisane ustawienia połączenia

Subiekt GT korzysta z pliku gt.ini, czyli pliku konfiguracyjnego zawierającego między innymi informacje potrzebne do wskazania serwera, instancji i ustawień połączenia. Błędna lub nieaktualna zawartość tego pliku może spowodować, że program próbuje łączyć się z dawnym komputerem albo nieistniejącą instancją.

Podczas diagnozy porównuje się ustawienia na działającym i niedziałającym stanowisku, o ile problem dotyczy tylko części komputerów. Sprawdza się, czy wskazany serwer jest taki sam, czy nazwa instancji odpowiada rzeczywistej usłudze oraz czy konfiguracja nie została przypadkowo nadpisana. Nie wystarczy skopiować pliku z innego komputera bez sprawdzenia, czy oba stanowiska korzystają z tej samej wersji programu, tego samego podmiotu i tego samego środowiska sieciowego.

Zmiana gt.ini bez kopii może utrudnić odtworzenie wcześniejszych ustawień. Dlatego plik jest najpierw zabezpieczany, a dopiero później analizowany. Sam plik nie zawiera danych całej bazy, ale może zawierać istotne informacje konfiguracyjne, których utrata wydłuży diagnostykę.

Sprawdzenie usługi SQL Server

Usługa SQL Server, czyli proces systemowy odpowiedzialny za obsługę baz danych, musi działać na komputerze pełniącym rolę serwera. Jeżeli jest zatrzymana, Subiekt GT nie połączy się z podmiotem, nawet gdy nazwa serwera i konto są poprawne. Sprawdza się stan usługi, sposób jej uruchamiania oraz ewentualne błędy zapisane w systemie.

Weryfikowana jest również usługa SQL Server Browser. Browser, czyli usługa pomagająca odnaleźć nazwaną instancję SQL Server w sieci, może być potrzebna przy określonej konfiguracji. Jej brak nie zawsze oznacza awarię, ponieważ połączenie może działać przy bezpośrednio wskazanym porcie. Nie należy jednak zakładać, że każda instalacja SQL Server wymaga identycznych usług.

Jeśli usługa zatrzymuje się ponownie po uruchomieniu, przyczyna może znajdować się w konfiguracji, zasobach systemu, plikach bazy albo uprawnieniach konta usługi. W takim przypadku samo ponowne uruchamianie nie rozwiązuje problemu i może zwiększyć ryzyko pracy na niespójnym środowisku.

TCP/IP, port i zapora systemowa

SQL Server może komunikować się przez protokół TCP/IP, czyli standard używany do przesyłania danych między komputerami w sieci. Gdy protokół jest wyłączony, stanowisko nie połączy się z serwerem mimo prawidłowego wpisu w konfiguracji. Sprawdza się ustawienia protokołów dla właściwej instancji, port nasłuchu oraz zgodność tych danych z konfiguracją klienta.

Zapora systemowa, czyli mechanizm filtrujący połączenia przychodzące i wychodzące, może blokować ruch do SQL Server. Dotyczy to zwłaszcza zmian po aktualizacji systemu, wymianie routera albo zmianie profilu sieci. Reguła zapory powinna dotyczyć właściwej usługi lub portu, a nie przypadkowo całego komputera. Wyłączenie zapory bez kontroli zakresu i późniejszego przywrócenia ochrony nie jest prawidłową metodą naprawy.

Analizuje się także, czy komputery znajdują się w tej samej sieci i czy serwer odpowiada pod właściwą nazwą. Problem z DNS, czyli mechanizmem tłumaczącym nazwy komputerów na adresy IP, może sprawić, że nazwa serwera przestaje działać, choć połączenie po adresie nadal jest możliwe. Taki test pomaga rozdzielić problem nazwy od problemu samej usługi.

Zły katalog bazy lub niewłaściwy podmiot

Subiekt GT może wskazywać bazę, która została przeniesiona, odtworzona pod inną nazwą albo pozostaje w innym środowisku SQL Server. Komunikat o nieznalezieniu bazy nie musi oznaczać jej usunięcia. Baza może istnieć, ale konto nie ma do niej dostępu, jest w stanie odtwarzania albo program odwołuje się do nieaktualnego katalogu.

Katalog bazy, czyli miejsce i nazwa obiektu przechowywanego przez SQL Server, jest sprawdzany na poziomie serwera, a nie przez przypadkowe wyszukiwanie plików w Eksploratorze. Bezpośrednie przenoszenie plików baz danych, zmiana nazw plików lub podłączanie ich do innej instancji bez przygotowania może doprowadzić do niespójności.

Jeśli pojawił się wybór niewłaściwego podmiotu, trzeba ustalić, czy problem dotyczy tylko listy podmiotów, czy również samego połączenia. Działa połączenie z serwerem, ale nie działa otwarcie konkretnej bazy, co wskazuje na inny etap diagnozy niż całkowity brak dostępu do SQL Server.

Bezpieczna kolejność diagnozy

Prace rozpoczynają się od zebrania informacji: kiedy pojawił się błąd, czy zmieniano komputer lub sieć, czy problem występuje na jednym stanowisku i jaki dokładnie tekst zawiera komunikat. Następnie zabezpieczana jest kopia bazy. Kopia zapasowa, czyli dodatkowe zapisanie danych umożliwiające ich odtworzenie, jest wykonywana przed ingerencją w bazę lub jej konfigurację.

1. Sprawdzane jest, czy komputer z SQL Server działa i czy dostępna jest właściwa usługa.
2. Weryfikowana jest nazwa serwera, instancji oraz ustawienia zapisane w gt.ini.
3. Rozdziela się błąd odnalezienia serwera od błędu logowania i braku uprawnień.
4. Sprawdzane są protokół TCP/IP, port, zapora i komunikacja między stanowiskiem a serwerem.
5. Weryfikowana jest obecność właściwej bazy, jej stan oraz dostęp konta.
6. Po zmianach wykonywana jest próba połączenia i sprawdzana praca programu na odpowiednim podmiocie.

Taka kolejność ogranicza liczbę zmian i ułatwia ustalenie, która czynność przyniosła efekt. W przypadku rodziny InsERT GT analizowane mogą być także zależności z Rewizorem GT, Rachmistrzem GT, Gratyfikantem GT, Gestorem GT oraz Sferą GT. Sfera GT to interfejs programistyczny oparty na COM i OLE Automation, pozwalający innym aplikacjom współpracować z wybranymi programami InsERT GT.

Co można sprawdzić samodzielnie

Bezpieczne jest zapisanie dokładnej treści komunikatu, sprawdzenie, czy problem występuje na innych stanowiskach, oraz ustalenie, czy komputer pełniący rolę serwera jest włączony. Można również sprawdzić, czy połączenie z innymi elementami sieci działa oraz czy błąd pojawił się po konkretnej zmianie, na przykład aktualizacji lub wymianie routera.

Warto przygotować informacje o nazwie serwera, nazwie instancji, wersji Subiekta GT, nazwie podmiotu i sposobie logowania. Jeżeli dostępna jest aktualna kopia bazy, należy zachować ją w bezpiecznym miejscu. Takie dane pozwalają szybciej odróżnić problem lokalny od awarii środowiska serwerowego.

Nie należy samodzielnie usuwać baz, zmieniać nazw plików, odłączać bazy, kasować kont SQL Server ani wyłączać zabezpieczeń na stałe. Nie należy także uruchamiać przypadkowych narzędzi naprawczych znalezionych w internecie, szczególnie gdy nie wiadomo, z jaką wersją SQL Server i Subiekta GT współpracują.

Błędy podczas samodzielnych prób naprawy

Częstym błędem jest wielokrotne wpisywanie hasła bez sprawdzenia, czy logowanie odbywa się do właściwej instancji. Może to prowadzić do blokady konta. Innym problemem jest zmiana gt.ini na jednym komputerze, gdy rzeczywista przyczyna znajduje się w usłudze SQL Server albo zaporze.

Ryzykowne jest również odtwarzanie kopii bazy bez upewnienia się, że jest to najnowszy właściwy plik. Odtworzenie starszej kopii może zastąpić aktualne dane. Przed taką operacją trzeba ustalić datę kopii, jej pochodzenie i zakres danych, a także zachować bieżący stan środowiska.

Nie powinno się traktować ponownej instalacji programu jako pierwszej metody. Instalacja może nie zmienić niczego, jeśli problem dotyczy sieci, konta lub usługi SQL Server. Może też nadpisać ustawienia, których później zabraknie do porównania.

Kiedy przyczyna leży poza połączeniem Subiekta GT

Jeśli Subiekt GT uruchamia się, otwiera podmiot, ale nie działa konkretna operacja, problem może dotyczyć uprawnień w programie, konfiguracji modułu albo danych konkretnego dokumentu. Nie jest to już typowy błąd nawiązania połączenia z SQL Server.

Gdy działają wszystkie funkcje programu, a nie działa integracja ze sklepem internetowym, diagnozuje się osobno konfigurację integracji, dane dostępowe, synchronizację i komunikację z usługą sklepu. Integracje ze sklepem dotyczą w tej rodzinie wyłącznie Subiekta GT. Rewizor GT, Rachmistrz GT, Gratyfikant GT i Gestor GT mogą być obsługiwane bez integracji ze sklepem.

Jeżeli problem dotyczy urządzenia fiskalnego, nie musi oznaczać awarii SQL Server. Urządzenia fiskalne nie są naprawiane, natomiast można sprawdzić sterowniki i konfigurację współpracy z programem. Podobnie sam monitor, drukarka lub inne urządzenie może wymagać osobnej diagnozy. Drukarki i kserokopiarki są objęte wyłącznie konfiguracją, a nie naprawą.

Ile trwa usunięcie problemu

Czas zależy od tego, czy przyczyną jest pojedynczy wpis w konfiguracji, zatrzymana usługa, konto, zapora czy problem ze stanem bazy. Po ustaleniu źródła błędu naprawa jest z reguły wykonywana do 3 dni. Przyspieszanie i czyszczenie sprzętu może zostać wykonane do 24 godzin, jednak nie każdy problem z połączeniem Subiekta GT jest związany ze sprzętem.

W przypadku pracy door-to-door laptop może zostać odebrany i zwrócony przez kierowcę, a diagnoza laptopa w tym trybie wynosi 0 zł. Przy komputerze stacjonarnym diagnostyka wynosi 200 zł i jest zaliczana na poczet naprawy. Wizyta serwisanta ma bezpłatny dojazd, ale praca serwisanta jest zawsze płatna. Te zasady dotyczą sposobu obsługi i nie zastępują ustalenia przyczyny błędu w konkretnej konfiguracji.

Pytania, które pomagają zawęzić przyczynę

Czy błąd pojawia się na wszystkich stanowiskach? Jeśli tak, większe znaczenie mają usługa SQL Server, serwer, konto, zapora lub sieć. Jeśli problem dotyczy jednego komputera, sprawdzane są przede wszystkim gt.ini, lokalne ustawienia sieci i uprawnienia tego stanowiska.

Czy komunikat mówi o logowaniu, czy o braku serwera? Informacja o logowaniu wskazuje na konto lub uprawnienia. Informacja o braku serwera kieruje diagnozę w stronę nazwy instancji, usługi, portu, protokołu TCP/IP albo zapory.

Czy ostatnio zmieniano nazwę komputera lub router? Taka zmiana może wpłynąć na adres serwera, rozpoznawanie nazwy i reguły zapory. Wtedy warto zachować wcześniejsze ustawienia zamiast od razu je nadpisywać.

Czy istnieje aktualna kopia bazy? Jest to istotne przed odtwarzaniem, podłączaniem lub inną ingerencją w bazę. Sama obecność pliku kopii nie wystarcza, jeśli nie wiadomo, z jakiego podmiotu i momentu pochodzi.

Podsumowanie diagnozy połączenia z SQL Server

Błąd połączenia Subiekta GT z SQL Server należy rozpatrywać jako problem kilku warstw: konfiguracji programu, usługi serwerowej, konta, sieci, portu, zapory i dostępu do konkretnej bazy. Najbezpieczniejsza kolejność zaczyna się od dokładnego komunikatu i kopii danych, a kończy na kontrolowanym sprawdzeniu połączenia. Dzięki temu można odróżnić błąd gt.ini od awarii usługi, problem logowania od blokady sieci oraz brak bazy od braku uprawnień.