Wdrożenie drugiego lub kolejnego stanowiska pracy w firmie niemal zawsze wiąże się z koniecznością zapewnienia dostępu do wspólnej bazy danych. Program handlowo-magazynowy lub kadrowy zainstalowany na komputerze głównym działa bez zakłóceń, jednak próba uruchomienia programu na nowo podłączonym laptopie w tym samym biurze kończy się niepowodzeniem. Ekran powitalny programu zawiesza się na etapie łączenia, a po chwili pojawia się komunikat o braku odpowiedzi serwera bazy danych. Taka sytuacja paraliżuje pracę działu sprzedaży, magazynu lub księgowości, uniemożliwiając wystawianie dokumentów i jednoczesną obsługę klientów.
Silnik Microsoft SQL Server odpowiada za bezpieczne przechowywanie, przetwarzanie i udostępnianie struktur danych wykorzystywanych przez oprogramowanie do zarządzania przedsiębiorstwem. Domyślna konfiguracja tego środowiska po instalacji jednostanowiskowej jest zoptymalizowana pod kątem działania wyłącznie na maszynie lokalnej. Oznacza to, że mechanizmy komunikacji sieciowej pozostają wyłączone ze względów bezpieczeństwa. Dopóki z programu korzysta jedna osoba na jednym komputerze, problem nie występuje. Schody zaczynają się w momencie, gdy inne komputery w sieci lokalnej muszą wysyłać zapytania do tej samej bazy danych.
Problemy z dostępem do centralnej bazy danych zgłaszane przez pracowników biurowych mają zazwyczaj bardzo konkretny przebieg:
Brak łączności między stanowiskiem klienckim a instancją Microsoft SQL Server wynika z określonych barier konfiguracyjnych w systemie operacyjnym, strukturze sieciowej lub w samym silniku bazodanowym:
To najczęstsza przyczyna problemów po świeżej instalacji oprogramowania. Microsoft SQL Server Configuration Manager — narzędzie administracyjne do zarządzania usługami i protokołami sieciowymi bazy — w wersjach jednostanowiskowych pozostawia protokół TCP/IP w stanie nieaktywnym. Komunikacja między procesami odbywa się wówczas wyłącznie przez pamięć współdzieloną (Shared Memory), co całkowicie uniemożliwia przesyłanie pakietów przez sieć LAN.
Systemowa zapora sieciowa na komputerze pełniącym rolę serwera bazy danych domyślnie blokuje przychodzący ruch na portach sieciowych. Domyślna instancja Microsoft SQL Server nasłuchuje zapytań na porcie TCP 1433. Jeśli w regułach zapory nie zostanie utworzony wyjątek dla tego portu lub dla samego pliku wykonywalnego silnika bazodanowego, pakiety przesyłane ze stanowisk podrzędnych zostaną bez ostrzeżenia odrzucone.
W środowiskach, w których zainstalowano instancję nazwaną (często tworzoną automatycznie przez instalatory programów handlowych), silnik bazy nie korzysta ze stałego portu, lecz przydziela porty dynamicznie. Za informowanie stanowisk klienckich, na jakim porcie aktualnie nasłuchuje dana instancja, odpowiada usługa SQL Server Browser, działająca na porcie UDP 1434. Gdy ta usługa jest wyłączona lub zablokowana przez zaporę, komputery w sieci nie potrafią zlokalizować bazy danych po jej nazwie.
Silnik może pracować w trybie uwierzytelniania zintegrowanego z systemem Windows (Windows Authentication) lub w trybie mieszanym (Mixed Mode), który dopuszcza logowanie za pomocą wewnętrznych kont bazy danych. W sieciach lokalnych bez domeny Active Directory brak włączonego trybu mieszanego uniemożliwia zalogowanie się użytkownikom z innych komputerów za pomocą loginu i hasła zdefiniowanego w programie finansowo-magazynowym.
Aktualizacje systemu Windows lub zmiany w routerze potrafią samoczynnie przełączyć profil sieci lokalnej z prywatnego na publiczny. W profilu publicznym systemowe mechanizmy obronne automatycznie uszczelniają zaporę i wyłączają odnajdowanie urządzeń. Dodatkowo, jeśli komputer z bazą danych otrzymuje adres IP dynamicznie z routera (przez DHCP), każda zmiana adresu po restarcie routera zerwie połączenie ze wszystkimi stanowiskami w biurze.
Wdrożenie stabilnej pracy wielostanowiskowej wymaga metodycznego podejścia, obejmującego zarówno weryfikację środowiska sieciowego, jak i bezpośrednie parametryzowanie usług bazodanowych. Dojeżdżamy do siedziby klienta i realizujemy pełną procedurę konfiguracyjną na miejscu:
W pierwszym kroku przeprowadzamy analizę infrastruktury lokalnej. Weryfikujemy stabilność połączeń kablowych i bezprzewodowych oraz konfigurację adresacji na routerze. Przypisujemy komputerowi głównemu stały adres IP w sieci lokalnej (statyczna dzierżawa DHCP), co zapobiega gubieniu ścieżki do bazy przez programy klienckie po ponownym uruchomieniu sprzętu.
Następnie przechodzimy do konfiguracji w Microsoft SQL Server Configuration Manager. Aktywujemy protokół TCP/IP dla właściwej instancji serwera, wyłączamy niepotrzebne protokoły i precyzyjnie definiujemy właściwości nasłuchu na wszystkich kartach sieciowych (sekcja IPAll). W zależności od architektury programu ustawiamy nasłuch na stałym porcie TCP 1433 lub konfigurujemy porty dynamiczne w powiązaniu z usługą przeglądarki SQL Server Browser, której tryb uruchamiania zmieniamy na automatyczny.
Kolejnym etapem jest dostosowanie Zapory Windows Defender oraz ewentualnych pakietów zabezpieczających zainstalowanych w systemie. Tworzymy dedykowane reguły dla ruchu przychodzącego, obejmujące port TCP 1433, port UDP 1434 oraz bezpośrednie wyjątki dla procesu sqlservr.exe. Wszystkie wpisy ograniczamy ściśle do profilu sieci prywatnej, dbając o to, by komputer nie był narażony na nieautoryzowany dostęp z zewnątrz.
Za pomocą narzędzia Microsoft SQL Server Management Studio (SSMS) weryfikujemy tryb uwierzytelniania instancji, przestawiając go w razie potrzeby na tryb mieszany. Sprawdzamy uprawnienia kont bazodanowych oraz konfigurację blokowania kont przy błędnych próbach logowania. Na koniec instalujemy i konfigurujemy oprogramowanie klienckie na komputerach pracowników, wprowadzając poprawne parametry połączenia z wykorzystaniem stałego adresu IP lub zweryfikowanej nazwy sieciowej komputera głównego.
W małych biurach bazę danych można z powodzeniem uruchomić na zwykłym komputerze stacjonarnym lub wydajnym laptopie, który jednocześnie służy jednemu z pracowników do codziennych zadań. Należy jednak pamiętać, że komputer ten musi pozostać włączony przez cały czas pracy pozostałych stanowisk, a jego usypianie lub wyłączanie przerwie sesje innym użytkownikom.
Transmisja bezprzewodowa jest podatna na chwilowe zakłócenia sygnału i spadki przepustowości. O ile przeglądanie danych jest możliwe, o tyle zapisywanie dużych dokumentów lub wykonywanie operacji księgowych przy niestabilnym łączu Wi-Fi niesie ryzyko zerwania transakcji. Dla komputera głównego z bazą danych zawsze zalecamy bezpośrednie połączenie kablem sieciowym Ethernet.
Spadek wydajności może wynikać z ograniczeń sprzętowych komputera głównego (zbyt mała ilość pamięci RAM, wolny dysk talerzowy zamiast nośnika SSD) lub z limitów samej bezpłatnej edycji silnika SQL Server Express, która wykorzystuje maksymalnie określoną liczbę rdzeni procesora i ograniczoną pamięć operacyjną. Diagnozujemy wąskie gardła sprzętowe i optymalizujemy parametry buforowania.
Silnik Microsoft SQL Server korzysta z mechanizmu transakcyjności oraz dziennika transakcji (Transaction Log). Oznacza to, że operacja jest zatwierdzana w bazie dopiero po jej pełnym wykonaniu. Nagłe zerwanie połączenia sieciowego powoduje wycofanie niezakończonej operacji, co chroni bazę przed uszkodzeniem struktury, jednak niezapisany formularz na stanowisku pracownika trzeba będzie wypełnić ponownie.
Próby samodzielnego rozwiązywania problemów z siecią i bazą danych często prowadzą do poważniejszych komplikacji. Aby uniknąć utraty stabilności systemu i bezpieczeństwa danych, należy przestrzegać kilku podstawowych zasad:
Zanim wezwiesz pomoc techniczną, możesz wykonać kilka podstawowych testów weryfikacyjnych:
Gdy błędy konfiguracji uniemożliwiają bieżącą pracę firmy, a procedury sieciowe wymagają specjalistycznej wiedzy, warto skorzystać z pomocy wykwalifikowanego serwisu. Dojeżdżamy bezpośrednio do biura klienta, co pozwala przeprowadzić rzetelną diagnozę całego środowiska — od fizycznych połączeń kablowych, przez routery, aż po ustawienia systemowe i parametry silnika bazodanowego na poszczególnych stacjach roboczych.
Przed przystąpieniem do jakichkolwiek modyfikacji konfiguracji serwisant przeprowadza weryfikację stanu technicznego i przedstawia dokładną wycenę planowanych prac. Klient podejmuje decyzję o realizacji zlecenia mając pełną jasność co do zakresu czynności. Jeśli problem z wydajnością bazy danych wynika z usterki sprzętowej komputera głównego (np. uszkodzenie nośnika pamięci masowej lub układu zasilania płyty głównej), odbieramy sprzęt do warsztatu i odwozimy po naprawie oraz ponownej instalacji komponentów. Wszelkie naprawy sprzętowe realizujemy przy użyciu wyłącznie nowych części zamiennych, a wykonane usługi objęte są gwarancją do 12 miesięcy. Na życzenie klienta bezpłatnie podpisujemy umowę o poufności (NDA), co gwarantuje pełne bezpieczeństwo wrażliwych danych handlowych i finansowych firmy.
W celu zgłoszenia problemu z konfiguracją wielostanowiskową lub zamówienia wizyty serwisanta w biurze prosimy o kontakt telefoniczny pod numerem 22 257 87 54.
Nie wiesz, od czego zacząć? Zadzwoń.
Porada telefoniczna nic nie kosztuje, a część usterek udaje się rozwiązać bez dojazdu — zwłaszcza tych, w których winne są ustawienia albo zasilanie. Jeżeli trzeba przyjechać, dojazd, odbiór i zwrot sprzętu są bezpłatne, a diagnoza laptopa przy odbiorze — również. Wizyta serwisanta u klienta jest płatna; sam dojazd i tak nic nie kosztuje.
Telefon odbieramy całą dobę, siedem dni w tygodniu — także w weekendy i święta. Dojeżdżamy na terenie Warszawy i siedmiu przyległych powiatów.
Serwis laptopów i komputerów na warszawskim Bemowie. Przyjeżdżamy pod wskazany adres — do domu i do firmy. Dojazd, odbiór i zwrot nic nie kosztują, a diagnoza laptopa przy odbiorze sprzętu jest bezpłatna.
ul. Lazurowa 14b
01-474 Warszawa — Bemowo
Biuro bez obsługi klientów. Sprzętu nie trzeba nigdzie przywozić.
Odbieramy także w weekendy i święta. Przy pilnych zgłoszeniach umawiamy się na ten sam dzień.
Dojazd: Warszawa i siedem przyległych powiatów, w promieniu 40 km. Na miejscu jesteśmy z reguły w ciągu godziny.
Na wykonane naprawy dajemy gwarancję do 12 miesięcy.
