Przerwy w połączeniu sieciowym między stacją roboczą a serwerem SQL to jeden z najbardziej frustrujących problemów użytkowników Comarch ERP Optima. Mogą objawiać się zawieszaniem programu, komunikatami o utracie połączenia, cofniętymi transakcjami lub niemożnością zalogowania się. Opisujemy systematyczne podejście do diagnozowania i naprawiania takich problemów.
Klasyfikacja problemów sieciowych w Optima
Problemy sieciowe wpływające na Comarch ERP Optima można podzielić na: trwałe (Optima w ogóle nie łączy się z serwerem – problemy konfiguracyjne), przerywające (połączenie jest niestabilne, Optima gubi sesję w trakcie pracy – problemy infrastruktury sieciowej), wolne (połączenie działa, ale Optima jest powolna – wąskie gardło przepustowości lub obciążenie serwera). Każdy typ wymaga innego podejścia diagnostycznego.
Narzędzia diagnostyki sieciowej
Podstawowy zestaw narzędzi do diagnostyki: ping NAZWASERVERA -t – ciągły ping, obserwuj czy są utracone pakiety (wskazuje niestabilność łącza), tracert NAZWASERVERA – śledzenie trasy pakietów (gdzie jest opóźnienie), nslookup NAZWASERVERA – weryfikacja rozwiązywania DNS, telnet NAZWASERVERA 1433 – test czy port SQL jest dostępny, netstat -an | findstr :1433 – weryfikacja nasłuchiwania SQL na porcie. Wykonaj te testy ze stacji roboczej mającej problem.
Niestabilne połączenie Wi-Fi jako przyczyna problemów Optimy
Comarch ERP Optima, jak każda aplikacja bazodanowa działająca w architekturze klient-serwer, jest bardzo wrażliwa na przerwy w połączeniu sieciowym. Nawet chwilowy zanik połączenia Wi-Fi (0,5–1 sekunda) może spowodować utratę niezapisanej transakcji SQL i komunikat o błędzie. Stanowiska, na których intensywnie pracuje się z Optimą, powinny być podłączone przez kabel Ethernet. Jeżeli Wi-Fi jest konieczne, sprawdź jakość sygnału (siła > -65 dBm) i przełącz na pasmo 5 GHz.
Blokowanie przez zaporę sieciową lub program antywirusowy
Nagłe problemy z połączeniem po instalacji nowego oprogramowania bezpieczeństwa lub po aktualizacji systemu mogą wynikać z blokady przez zaporę. Sprawdź logi zapory na serwerze i stacji roboczej pod kątem blokowanych połączeń na port 1433. Tymczasowo wyłącz zaporę (tylko do testu) i sprawdź, czy problem zniknął. Jeżeli tak, dodaj odpowiednie reguły zezwalające i ponownie włącz zaporę. Programy antywirusowe z funkcją IPS (Intrusion Prevention) mogą też blokować połączenia SQL jako podejrzane.
Problemy z VPN w środowiskach pracy zdalnej
Praca przez VPN z Comarch ERP Optima jest możliwa, ale wymaga stabilnego VPN z niskim latencją. Tunele VPN SSL (OpenVPN, WireGuard) zazwyczaj sprawdzają się lepiej niż starsze IPSec/L2TP. Sprawdź, czy MTU VPN jest właściwie skonfigurowane (problem fragmentacji pakietów to częsta przyczyna zawieszania się SQL przez VPN). Jeżeli VPN powoduje problemy, rozważ migrację Optimy na serwer terminali dostępny przez RDP zamiast bezpośredniego dostępu SQL przez VPN.
Naprawa po utracie połączenia w trakcie operacji
Gdy połączenie sieciowe zostało utracone w trakcie operacji w Optima (np. zapisu dokumentu), po przywróceniu połączenia sprawdź: czy dokument został zapisany (otwórz go na liście), czy nie ma otwartej transakcji blokującej inne operacje (w SSMS sprawdź sys.dm_exec_requests). Jeżeli Optima zgłasza błąd transakcji przy próbie zapisu, zamknij program, poczekaj 30 sekund i otwórz ponownie – SQL Server automatycznie wycofa niezakończoną transakcję.
