Czy Subiekt GT wymaga ręcznej konfiguracji SQL?

Subiekt GT może wymagać ręcznej konfiguracji SQL Server w bardziej złożonych scenariuszach wdrożeniowych.

Kiedy instalacja Subiekta GT nie kończy się na ustawieniach programu

Subiekt GT korzysta z bazy danych Microsoft SQL Server, dlatego zakres konfiguracji zależy nie tylko od samego programu InsERT, lecz także od sposobu przygotowania serwera bazodanowego. W typowym stanowisku biurowym instalator może utworzyć lub wykorzystać lokalną instancję SQL Server i przeprowadzić użytkownika przez podstawowe ustawienia. Nie oznacza to jednak, że każda instalacja wygląda tak samo. Ręczna konfiguracja staje się potrzebna wtedy, gdy baza ma działać na innym komputerze, gdy w systemie istnieje już używana instancja SQL Server albo gdy środowisko sieciowe ma niestandardowe zasady dostępu.

Do prostego uruchomienia Subiekta GT zwykle wystarcza poprawnie zainstalowany silnik SQL Server, działająca usługa bazy danych oraz konto mające uprawnienia wymagane do utworzenia lub otwarcia bazy firmy. W bardziej złożonym wdrożeniu trzeba dodatkowo ustalić nazwę instancji, sposób uwierzytelniania, adres serwera, port komunikacyjny i prawa użytkowników. Błędne ustawienie któregoś z tych elementów może powodować komunikaty o braku połączenia, niewidocznej bazie albo odmowie dostępu, mimo że sam Subiekt GT został zainstalowany prawidłowo.

Instancja SQL Server, nazwa serwera i dostęp do bazy Subiekta

Najważniejszym punktem konfiguracji jest wskazanie właściwego wystąpienia SQL Server. Serwer może działać jako instancja domyślna albo jako instancja nazwana. W drugim przypadku nazwa połączenia zawiera nazwę komputera oraz nazwę instancji, na przykład w postaci NAZWA-KOMPUTERA\NAZWA-INSTANCJI. Sam adres IP komputera nie wystarcza, jeżeli klient musi jeszcze odnaleźć konkretną instancję. Przy pracy przez sieć należy również sprawdzić, czy instancja nasłuchuje na porcie dostępnym dla pozostałych stanowisk.

SQL Server może używać uwierzytelniania systemu Windows albo uwierzytelniania SQL Server, zależnie od konfiguracji środowiska i sposobu przygotowania kont. Konto Windows musi mieć odpowiednie prawa w SQL Server, a konto SQL Server wymaga poprawnego loginu, hasła i uprawnień do konkretnej bazy. Nie należy nadawać wszystkim użytkownikom uprawnień administratora serwera tylko po to, aby usunąć komunikat o odmowie dostępu. Prawa powinny odpowiadać rzeczywistej roli użytkownika Subiekta GT, a konto używane do czynności administracyjnych powinno być oddzielone od kont codziennej pracy.

Ręczna praca może obejmować także włączenie odpowiednich usług SQL Server, ustawienie protokołu TCP/IP w SQL Server Configuration Manager oraz dopuszczenie ruchu w Zaporze systemu Windows. Przy instancjach nazwanych znaczenie może mieć usługa SQL Server Browser, ponieważ pomaga klientom ustalić port instancji. Alternatywą jest wskazanie stałego portu i używanie go w regułach zapory oraz konfiguracji połączenia. Sama instalacja aplikacji na komputerze klienckim nie otwiera automatycznie wszystkich wymaganych połączeń sieciowych.

Przypadki wymagające świadomej konfiguracji i kontroli połączenia

Ręczna konfiguracja SQL Server jest szczególnie prawdopodobna przy przenoszeniu Subiekta GT na nowy komputer, podłączaniu kilku stanowisk do jednej bazy, korzystaniu z istniejącej infrastruktury SQL Server lub odtwarzaniu danych z kopii zapasowej. W każdym z tych przypadków trzeba rozdzielić trzy kwestie: czy usługa SQL Server działa, czy komputer klienta może nawiązać połączenie oraz czy zalogowane konto ma dostęp do właściwej bazy firmy. Spełnienie tylko jednego z tych warunków nie zapewnia poprawnego działania programu.

Przy diagnozie warto sprawdzić nazwę komputera i instancji, stan usługi SQL Server, dostępność portu z komputera klienckiego oraz wpisy w konfiguracji połączenia Subiekta GT. Należy również upewnić się, że baza nie została podłączona pod inną nazwą niż ta, której szuka program. Jeżeli połączenie działa lokalnie, ale nie działa z drugiego stanowiska, problem częściej dotyczy nasłuchu TCP/IP, zapory, rozwiązywania nazwy hosta albo uprawnień sieciowych niż instalacji samego Subiekta.

Po zmianie ustawień trzeba wykonać kontrolę praktyczną: otworzyć bazę na komputerze głównym, zalogować się z uprawnionego stanowiska klienckiego i sprawdzić podstawową operację na danych testowych lub bieżącej bazie zgodnie z procedurą firmy. Warto zweryfikować także, czy użytkownicy widzą właściwy podmiot, czy nie występują błędy logowania oraz czy kopia zapasowa może zostać wykonana i odtworzona. Konfiguracja nie jest zakończona w chwili, gdy instalator przestaje zgłaszać błędy; konieczne jest jeszcze potwierdzenie działania całego przepływu między programem, SQL Server i bazą firmy.

Zakres diagnostyki przy problemach z Subiektem GT i SQL Server

Jeżeli Subiekt GT nie łączy się z bazą, należy rozpocząć od zebrania konkretnych informacji: wersji zainstalowanego Subiekta GT, wersji używanego SQL Server, nazwy instancji, rodzaju uwierzytelniania, miejsca przechowywania bazy oraz tego, czy problem występuje lokalnie, czy tylko przez sieć. Pomocne jest także ustalenie, czy błąd pojawił się po zmianie komputera, adresacji sieciowej, hasła, zapory albo aktualizacji oprogramowania. Takie dane pozwalają odróżnić problem z usługą od problemu z uprawnieniami lub trasą sieciową.

Podczas naprawy nie powinno się pochopnie usuwać bazy, reinstalować SQL Server ani zmieniać trybu uwierzytelniania bez wcześniejszej kopii zapasowej i rozpoznania zależności. Najpierw należy potwierdzić, gdzie znajdują się pliki bazy, czy usługa SQL Server ma do nich dostęp oraz czy baza ma stan pozwalający na otwarcie. W przypadku odtwarzania kopii trzeba użyć procedury zgodnej z narzędziami Subiekta GT i SQL Server, a po operacji sprawdzić integralność danych oraz możliwość logowania użytkowników. Zmiana parametrów serwera może rozwiązać jeden problem, ale jednocześnie odłączyć inne stanowiska, dlatego każdą modyfikację należy odnotować i zweryfikować z perspektywy całej instalacji.

Wniosek jest praktyczny: Subiekt GT nie zawsze wymaga ręcznej konfiguracji SQL Server, ale w złożonym wdrożeniu konfiguracja ręczna może być konieczna. Dotyczy to przede wszystkim środowisk wielostanowiskowych, zdalnego dostępu do bazy, istniejących instancji SQL Server i niestandardowych zasad bezpieczeństwa. Prawidłowa procedura obejmuje identyfikację instancji, zapewnienie komunikacji, nadanie właściwych uprawnień, sprawdzenie bazy oraz test działania programu po zmianach. Dopiero taki zestaw kontroli potwierdza, że problem został usunięty, a nie tylko ukryty przez zmianę pojedynczego ustawienia.