Oprogramowanie firmowe

Mechanizm komunikacji programu księgowego z bazą danych

Program księgowy Rewizor GT opiera swoje działanie na architekturze klient-serwer. Oznacza to, że sama aplikacja zainstalowana na stanowisku roboczym nie przechowuje bezpośrednio tabel z zapisami księgowymi, planem kont czy dokumentami finansowymi. Wszystkie te informacje znajdują się w relacyjnej bazie danych obsługiwanej przez odrębny silnik bazodanowy — najczęściej uruchomiony na wyznaczonym komputerze pełniącym funkcję serwera lub na stanowisku głównym. Aplikacja kliencka łączy się z serwerem bazodanowym za pośrednictwem protokołów sieciowych, wysyłając zapytania i odbierając przetworzone pakiety danych.

W momencie wymiany komputera na nowy dochodzi do przerwania dotychczasowego łańcucha połączeń. Nowy system operacyjny posiada własne reguły bezpieczeństwa, inną konfigurację zapory sieciowej, brak zarejestrowanych bibliotek klienckich oraz inną tożsamość w sieci lokalnej. Zmiana nazwy stanowiska, zmiana wewnętrznego adresu sieciowego bądź brak autoryzacji sprawiają, że program uruchomiony na nowo wdrożonym urządzeniu nie potrafi odnaleźć instancji bazy danych w sieci lub otrzymuje odmowę dostępu podczas próby logowania.

Typowe objawy zgłaszane podczas próby uruchomienia

Użytkownicy po podłączeniu nowego stanowiska i próbie uruchomienia programu Rewizor GT najczęściej napotykają okno wyboru podmiotu, w którym lista baz danych jest całkowicie pusta. Kliknięcie opcji wyszukiwania lub próba wpisania adresu serwera kończy się długim oczekiwaniem, po którym na ekranie pojawia się komunikat o przekroczeniu limitu czasu połączenia lub braku odpowiedzi ze strony serwera.

W innych przypadkach program widzi nazwę serwera i pozwala wskazać właściwy podmiot, lecz próba zalokowania użytkownika kończy się natychmiastowym przerwaniem operacji z komunikatem o błędzie autoryzacji bądź braku odpowiednich uprawnień. Zdarza się również, że połączenie zostaje nawiązane, jednak po kilku sekundach program zawiesza się podczas wczytywania początkowych parametrów księgowych, co uniemożliwia jakąkolwiek bieżącą pracę biura rachunkowego lub działu finansowego.

Warianty tego samego problemu

Problem z brakiem komunikacji przybiera różne formy w zależności od tego, jaką rolę w strukturze firmy pełnił wymieniany komputer oraz jak zorganizowana jest sieć lokalna.

Wymiana stanowiska klienckiego w sieci wielostanowiskowej

Gdy wymieniany jest komputer pracownika, a serwer bazy danych pozostał bez zmian, źródło trudności leży wyłącznie po stronie nowej stacji lub jej relacji z siecią. Program zainstalowany na świeżym systemie próbuje nawiązać sesję z serwerem, ale blokują go lokalne zabezpieczenia, brak właściwie wskazanego adresu serwera w konfiguracji połączenia lub niewłaściwy typ uwierzytelniania w silniku bazy danych.

Wymiana komputera głównego pełniącego funkcję serwera

Sytuacja jest bardziej złożona, gdy nowy sprzęt ma przejąć rolę serwera, na którym przechowywana jest baza danych. W takim scenariuszu konieczne jest nie tylko poprawne odtworzenie bazy z archiwum, ale także uruchomienie i właściwe skonfigurowanie samego silnika bazodanowego. Silnik musi nasłuchiwać zapytań przychodzących z sieci lokalnej, mieć włączone odpowiednie protokoły komunikacyjne oraz udostępniać właściwe porty przez zaporę sieciową.

Instalacja jednostanowiskowa przenoszona na nowy sprzęt

W przypadku pracy jednostanowiskowej, gdzie program i baza działają na tej samej maszynie, problemem bywa nieuruchomiona usługa silnika bazy danych w systemie operacyjnym. Nowa instalacja może posiadać inną nazwę instancji bazy, przez co Rewizor GT wysyła zapytania pod domyślny adres, podczas gdy usługa zarejestrowała się pod inną nazwą systemową.

Możliwe przyczyny braku połączenia z bazą

Źródła problemów z łącznością można uszeregować według prawdopodobieństwa ich wystąpienia, od kwestii konfiguracyjnych po błędy uprawnień:

• Blokady zapory sieciowej (firewall) — zapora na komputerze serwerowym lub na nowym stanowisku domyślnie odrzuca pakiety przychodzące na portach używanych przez silnik bazy danych oraz usługę rozpoznawania nazw instancji.
• Wyłączone protokoły sieciowe w silniku bazy danych — domyślna instalacja serwera bazodanowego bardzo często ma wyłączoną obsługę protokołu TCP/IP dla połączeń zdalnych, zezwalając wyłącznie na połączenia z poziomu pamięci lokalnej (Shared Memory).
• Błędne wskazanie serwera w konfiguracji programu — wpisanie samej nazwy komputera zamiast pełnej ścieżki zawierającej nazwę instancji bazy danych, co uniemożliwia programowi odnalezienie właściwego procesu w systemie.
• Problemy z translacją nazw w sieci lokalnej (DNS/NetBIOS) — nowy komputer nie potrafi przetłumaczyć nazwy sieciowej serwera na właściwy adres IP w sieci lokalnej, przez co pakiety nie trafiają pod właściwy adres.
• Niezgodność trybu uwierzytelniania i uprawnień użytkowników — serwer bazodanowy wymaga autoryzacji kontem bazodanowym, podczas gdy nowy system próbuje logować się za pośrednictwem konta użytkownika systemu Windows, które nie zostało zdefiniowane na serwerze.
• Różnice w zainstalowanych sterownikach i bibliotekach dostępu do danych — brak odpowiednich komponentów systemowych odpowiedzialnych za pośredniczenie między aplikacją a serwerem bazy na nowym komputerze.

Przebieg profesjonalnej diagnozy i konfiguracji

Podczas wizyty serwisant realizuje usystematyzowany proces weryfikacji całego środowiska, co pozwala wyeliminować źródło usterki bez ryzyka naruszenia spójności danych księgowych.

Pierwszym krokiem jest weryfikacja stanu usługi silnika bazy danych. Sprawdzane jest, czy usługa pracuje stabilnie, czy została skonfigurowana do automatycznego startu wraz z systemem oraz czy właściwie przydzielono jej uprawnienia konta systemowego. Następnie przeprowadzana jest inspekcja menedżera konfiguracji serwera bazodanowego w celu upewnienia się, że protokół TCP/IP jest aktywny i przypisany do właściwych interfejsów sieciowych.

Kolejny etap obejmuje konfigurację zapory sieciowej (firewall). Reguły bezpieczeństwa muszą precyzyjnie zezwalać na ruch dla pliku wykonywalnego serwera bazy danych oraz usługi przeglądarki bazy danych (odpowiedzialnej za rozgłaszanie instancji w sieci), a także na ruch na dedykowanych portach komunikacyjnych. Wprowadzanie tych wyjątków odbywa się z zachowaniem zasad bezpieczeństwa sieci lokalnej.

Po stronie nowego komputera sprawdzana jest widoczność serwera w sieci poprzez bezpośrednie testy pakietowe oraz testy połączeń na poziomie portów. Jeśli sieć lokalna nie radzi sobie z translacją nazw maszyn, wprowadzane jest stałe mapowanie adresów lub odpowiednia konfiguracja plików systemowych. Następnie serwis konfiguruje profil połączenia w programie Rewizor GT, wskazując precyzyjny adres instancji oraz odpowiedni mechanizm autoryzacji.

Gdy zachodzi potrzeba przeniesienia podmiotu ze starego sprzętu, przeprowadzana jest dearchiwizacja bazy danych z przygotowanej wcześniej kopii bezpieczeństwa, z zachowaniem pełnej integralności struktury i uprawnień użytkowników.

Czego nie robić i co można sprawdzić samodzielnie

W przypadku problemów z bazą danych nieostrożne działania mogą doprowadzić do uszkodzenia plików lub destabilizacji bezpieczeństwa całej sieci firmowej. Warto wiedzieć, jakich kroków unikać, a co można bezpiecznie zweryfikować.

Czynności, których nie należy wykonywać na własną rękę:

• Nie należy całkowicie wyłączać zapory sieciowej ani programów antywirusowych na serwerze — tworzy to bezpośrednie zagrożenie dla bezpieczeństwa danych firmowych.
• Nie wolno modyfikować plików bazy danych bezpośrednio w katalogach systemowych ani zmieniać ich rozszerzeń.
• Nie należy wielokrotnie wymuszać ponownej instalacji programu ani silnika bazy danych bez wcześniejszego zabezpieczenia kopii zapasowej, gdyż grozi to nadpisaniem istniejących podmiotów.
• Nie należy zmieniać haseł systemowych do kont technicznych silnika bazy, jeśli nie ma pewności, jakie inne usługi z nich korzystają.

Bezpieczne czynności wstępne przed przyjazdem serwisu:

• Upewnienie się, że nowy komputer ma stabilne połączenie z tą samą siecią lokalną (przewodową lub bezprzewodową), w której pracuje serwer bazy danych.
• Sprawdzenie, czy komputer pełniący funkcję serwera jest włączony i czy nie przeszedł w stan uśpienia.
• Przygotowanie informacji o tym, z którego komputera dotychczas korzystano oraz gdzie znajduje się ostatnia wykonana kopia zapasowa danych księgowych.

Wsparcie techniczne na miejscu i organizacja obsługi

Konfiguracja połączeń bazodanowych dla programów finansowo-księgowych wymaga precyzyjnego dopasowania parametrów sieci i systemu. Nasz serwis realizuje pełną diagnostykę oraz konfigurację oprogramowania Rewizor GT bezpośrednio w siedzibie firmy lub biurze klienta na terenie Warszawy i okolicznych powiatów.

Dojeżdżamy na miejsce awarii przez całą dobę, siedem dni w tygodniu, również w dni wolne i święta, co pozwala na szybkie przywrócenie ciągłości pracy działu księgowego bez przestojów w rozliczeniach. Zapewniamy pełną poufność — na życzenie klienta bezpłatnie podpisujemy umowę o zachowaniu poufności (NDA) przed przystąpieniem do jakichkolwiek prac na danych finansowych. Wszystkie czynności wykonują wyłącznie nasi wykwalifikowani pracownicy, bez pośredników i podwykonawców.

Każda interwencja rozpoczyna się od rzetelnej diagnozy środowiska sieciowego i weryfikacji stanu bazy danych. Po ustaleniu przyczyny braku połączenia przedstawiamy dokładny plan działania oraz indywidualną wycenę, którą klient akceptuje przed rozpoczęciem właściwych prac. Jeśli problem wymaga zaawansowanych napraw sprzętowych serwera lub stacji roboczej, odbieramy sprzęt do warsztatu własnym transportem i odwozimy po zakończonej naprawie.

W przypadku problemów z połączeniem programu Rewizor GT z bazą danych zapraszamy do kontaktu telefonicznego pod numerem 22 257 87 54.