Strona głównaBaza wiedzy

Comarch ERP Optima nie łączy się z SQL Server — co sprawdzić?

SQL Server Configuration Manager — protokoły instancji, przykład z poradnika BlueNetwork

Comarch ERP Optima · Poradnik techniczny

Optima nie łączy się z SQL?
Sprawdź połączenie krok po kroku.

Od nazwy instancji i stanu usługi po sieć, port oraz alias. Uporządkowana diagnostyka pomaga znaleźć przyczynę bez przypadkowej zmiany ustawień serwera.

Nazwa serweraUsługi i TCP/IPSieć i porty
Przykładowy widok protokołów instancji w SQL Server Configuration Manager
Zrzut z pierwotnego poradnika BlueNetwork. Wygląd zależy od wersji.

Ustal zakres problemu

Jedno stanowisko czy cała firma? To pierwszy trop przy szukaniu przyczyny.

Sprawdź kolejne warstwy

Nazwa, usługa, protokół i port wymagają oddzielnego sprawdzenia.

Zapisuj wyniki

Treść błędu i wykonane testy przyspieszają dalszą pomoc administratora.

Co dokładnie przestało działać?

Brak połączenia z Microsoft SQL Server może uniemożliwić uruchomienie Comarch ERP Optima lub dostęp do baz firmy. Podobny komunikat może mieć kilka przyczyn: błędną nazwę instancji, zatrzymaną usługę, problem z siecią albo odrzucone logowanie.

Zapisz pełną treść błędu, godzinę i okoliczności jego wystąpienia. Sprawdź, czy problem pojawił się po restarcie, aktualizacji, zmianie nazwy komputera, adresu IP lub konfiguracji sieci. Ustal też, czy inni użytkownicy mogą pracować.

SytuacjaOd czego zacząć
Problem na jednym stanowiskuPorównaj nazwę serwera, połączenie sieciowe i ustawienia klienta z działającym komputerem.
Problem na wszystkich stanowiskachSprawdź dostępność serwera, stan właściwej usługi SQL oraz ostatnie zmiany.
Na serwerze działa, zdalnie nieSkup się na TCP/IP, nazwach, trasie sieciowej i regułach zapory.
Komunikat „Login failed”Sprawdź uwierzytelnianie i szczegóły logowania; samo otwarcie portu może nie rozwiązać problemu.
Zacznij od sprawdzenia, nie od restartu. Restart usługi SQL przerywa pracę podłączonych użytkowników. Zmiany serwerowe wykonuj z administratorem, w uzgodnionym czasie.

Sprawdź nazwę serwera i instancji

W kreatorze przygotowania Optimy do uruchomienia sprawdź pole Serwer MS SQL. Dla instancji nazwanej zapis ma zwykle postać:

NAZWA_SERWERA\NAZWA_INSTANCJI

Przykład to SERWER\OPTIMA. Nazwa OPTIMA jest częsta w takich instalacjach, ale nie musi występować w Twoim środowisku. Porównaj wpis z konfiguracją działającego stanowiska lub informacją od administratora.

Sprawdź literówki, ukośnik i aktualną nazwę komputera. Po migracji baz lub wymianie serwera stary adres może nadal pozostawać na części stanowisk. Nie twórz nowej bazy konfiguracyjnej wyłącznie po to, aby ominąć błąd połączenia z istniejącą instalacją.

Czy właściwa usługa SQL jest uruchomiona?

  1. Na serwerze otwórz SQL Server Configuration Manager odpowiedni dla zainstalowanej wersji.
  2. Przejdź do SQL Server Services.
  3. Odszukaj SQL Server (nazwa_instancji), np. SQL Server (OPTIMA).
  4. Sprawdź stan usługi. Nie pomyl jej z inną instancją pracującą na tym samym komputerze.
  5. Jeśli nie działa lub nie daje się uruchomić, administrator powinien sprawdzić log SQL Server i systemowy dziennik zdarzeń.
Przykładowa lista usług SQL Server i SQL Server Browser
Lista usług — zrzut z artykułu BlueNetwork. Sprawdź rzeczywistą nazwę instancji.

Kiedy potrzebny jest SQL Server Browser?

Browser pomaga klientowi ustalić port instancji nazwanej. Korzysta z UDP 1434. Ma znaczenie, gdy połączenie opiera się na nazwie instancji i wykrywaniu jej portu.

Nie jest wymagany w każdej konfiguracji. Gdy klient łączy się bezpośrednio ze znanym portem TCP, może działać bez Browsera. Dlatego jego zatrzymanie samo w sobie nie przesądza o przyczynie awarii.

Kolejność sprawdzania

Stanowisko → sieć → instancja SQL

AdresCzy wskazujesz właściwy serwer?

Sprawdź nazwę, rozwiązywanie nazw i ewentualny alias.

TransportCzy osiągalny jest port?

Potwierdź protokół TCP i faktyczny port nasłuchu instancji.

LogowanieCzy serwer akceptuje dostęp?

Odczytaj szczegóły błędu oraz stan wymaganej bazy.

Sprawdź protokół, nazwę i faktyczny port

TCP/IP na serwerze

W SQL Server Configuration Manager otwórz SQL Server Network Configuration → Protocols for [nazwa instancji]. Sprawdź, czy TCP/IP jest włączony dla właściwej instancji. Zmiana stanu protokołu wymaga ponownego uruchomienia silnika, aby zaczęła obowiązywać — zaplanuj ją z administratorem.

Rozwiązywanie nazwy

Na stanowisku, z którego nie działa połączenie, można rozpocząć od polecenia:

Wiersz polecenia Windows · przykładping SERWER

Zastąp SERWER rzeczywistą nazwą hosta. Sprawdź, na jaki adres została rozwiązana nazwa. Brak odpowiedzi ICMP nie musi oznaczać niedostępności SQL — część urządzeń blokuje ping. Odpowiedź nie potwierdza natomiast, że działa port bazy.

Test połączenia TCP

Gdy administrator ustali numer portu, wykonaj w PowerShell test z konkretnego stanowiska:

PowerShell · zastąp przykładowy host i portTest-NetConnection -ComputerName SERWER -Port 1433

1433 jest tutaj przykładem. Instancja może używać innego portu, także dynamicznego. Numer ustal na podstawie konfiguracji lub aktualnego wpisu o nasłuchu w pliku SQL Server ERRORLOG. Lokalizacja logu zależy od wersji i instancji.

Wynik TcpTestSucceeded: True oznacza powodzenie testu TCP do wskazanego celu. Nie potwierdza jeszcze poprawnego logowania do SQL ani dostępu do bazy. Przy wyniku False sprawdź adres, nasłuch, trasę i zaporę; sam wynik nie wskazuje jednej konkretnej przyczyny.

Sprawdź zaporę dla tej instancji

Gdy SQL działa lokalnie, a połączenie z innego komputera nie dochodzi do skutku, administrator powinien zweryfikować zaporę serwera i zabezpieczenia po drodze.

  • Reguła musi obejmować rzeczywisty port TCP silnika albo właściwy plik sqlservr.exe.
  • Jeśli używany jest Browser, sprawdź również komunikację UDP 1434.
  • Zweryfikuj aktywny profil zapory oraz dozwolone adresy źródłowe.
  • Uwzględnij zapory innych producentów i reguły między segmentami sieci.

Zakres dostępu dobierz do zaufanych stanowisk lub sieci. Pozostaw zaporę włączoną; problem rozwiązuje się odpowiednią regułą. Nie wystawiaj usługi bazy bezpośrednio do internetu w ramach naprawy połączenia.

Nie otwieraj zestawu portów „na wszelki wypadek”. Starsze instrukcje mogą opisywać również usługi rozwiązywania nazw lub udostępniania plików, które nie są potrzebne w każdej współczesnej instalacji SQL.

Alias może pomóc wskazać właściwy cel

Alias jest lokalną nazwą połączenia, która wskazuje serwer, protokół i ewentualnie port. Może być przydatny przy migracji lub w środowisku wymagającym stałego adresowania. Nie naprawia zatrzymanej usługi ani zablokowanego portu.

  1. Najpierw ustal prawidłowy adres i port docelowej instancji.
  2. Dobierz narzędzie i konfigurację klienta do aplikacji oraz sterownika używanego na stanowisku.
  3. Ustaw nazwę aliasu, TCP/IP i właściwy cel połączenia.
  4. Jeśli konfiguracja wymaga stałego portu, podaj port potwierdzony przez administratora.
  5. W Optimie użyj uzgodnionej nazwy i sprawdź połączenie.
Przykładowe okno konfiguracji aliasu klienta SQL Server w cliconfg
Przykładowy alias z pierwotnego artykułu. Adresów i portów ze zrzutu nie należy kopiować do własnej konfiguracji.
Ważna jest architektura klienta, a nie tylko Windows. Na 64-bitowym Windows narzędzie C:\Windows\System32\cliconfg.exe jest 64-bitowe, a C:\Windows\SysWOW64\cliconfg.exe — 32-bitowe. Wybór musi odpowiadać używanemu klientowi. Sam fakt posiadania 64-bitowego systemu nie oznacza, że zawsze należy uruchamiać wariant z SysWOW64.

Alias jest ustawieniem po stronie klienta. Jeśli ma działać na wielu stanowiskach, każde musi mieć odpowiednią konfigurację. Obsługa zależy także od dostawcy połączenia. Dla SQL Server 2022 i nowszych Microsoft odsyła przy tworzeniu aliasów do SQL Server Client Network Utility zamiast Configuration Managera.

Odczytaj szczegóły błędu dostępu

Komunikat Login failed for user, często związany z błędem 18456, wskazuje na odrzucenie uwierzytelnienia. Przyczyną mogą być poświadczenia, stan konta, tryb logowania lub konfiguracja dostępu. Administrator powinien porównać komunikat klienta ze szczegółami w logu SQL Server.

Jeżeli połączenie dochodzi do silnika, lecz konkretna baza jest niedostępna, potrzebna jest oddzielna analiza jej stanu i uprawnień. Test otwartego portu nie odpowiada na te pytania.

Nie zmieniaj w ciemno haseł ani ustawień konta administracyjnego. Najpierw ustal, z jakiego sposobu logowania korzysta dana instalacja i które konto rzeczywiście zgłasza błąd.

Co przekazać osobie pomagającej?

Komunikat i czas

Pełna treść błędu oraz godzina jego wystąpienia.

Zakres problemu

Które stanowiska nie działają i czy połączenie lokalne na serwerze jest możliwe.

Środowisko

Wersja Optimy, nazwa instancji, wersja SQL i ostatnie zmiany.

Wykonane testy

Stan usługi, rozpoznany adres i wynik testu faktycznego portu.

Jeśli usługa nie startuje, problem dotyczy całej firmy albo potrzebna jest zmiana konfiguracji serwera, skontaktuj się z administratorem. W zgłoszeniu nie przesyłaj haseł ani kopii baz zwykłym e-mailem.

Gdy połączenie już działa, ale praca programu jest powolna, przejdź do osobnej diagnostyki wydajności. Przeczytaj nasz poradnik: optymalizacja baz SQL dla Comarch ERP Optima.

BlueNetwork · Comarch ERP Optima

Potrzebujesz pomocy z połączeniem?

Opisz objawy i wyniki dotychczasowych sprawdzeń. Pomożemy ustalić dalszą ścieżkę diagnostyki połączenia Optimy z SQL Server.

Skontaktuj się z BlueNetwork →
Źródła i ilustracje
Pierwotny artykuł BlueNetwork: „Co zrobić, gdy nie możemy połączyć się z serwerem SQL z Comarch ERP Optima”, 14.08.2024 · Microsoft: diagnostyka połączeń SQL Server
Opracowanie zaktualizowane 19.10.2026. Zrzuty ekranów pochodzą z pierwotnego poradnika i przedstawiają przykładowe widoki starszych narzędzi. Ustawienia należy dopasować do konkretnej instancji, aplikacji i wersji sterownika.

WIĘCEJ INFORMACJI

Informacje

Zapytaj o rozwiązanie

Znajdź na stronie