Error 40 – Nie można otworzyć połączenia

Error 40 sygnalizuje niemożność nawiązania połączenia z serwerem SQL, zwykle z powodu ustawień sieciowych lub zapory.

Co oznacza komunikat Error 40 w SQL Server

Komunikat „Named Pipes Provider, error: 40 – Could not open a connection to SQL Server” oznacza, że aplikacja kliencka SQL Server nie zdołała otworzyć połączenia z określoną instancją silnika. Nie jest to informacja o błędzie zapytania SQL, nieprawidłowej składni polecenia ani o odrzuceniu danych przez tabelę. Problem występuje wcześniej: klient nie może odnaleźć serwera, wybrać właściwej instancji albo nawiązać komunikacji z usługą działającą na komputerze docelowym.

Error 40 jest komunikatem warstwy dostępu do SQL Server. Często pojawia się razem z informacją „A network-related or instance-specific error occurred while establishing a connection to SQL Server”. Sama treść nie wskazuje jednej przyczyny. Taki rezultat może wystąpić, gdy usługa SQL Server jest zatrzymana, nazwa serwera została wpisana błędnie, instancja nie nasłuchuje na oczekiwanym protokole albo ruch blokuje zapora sieciowa. Dlatego diagnoza wymaga sprawdzenia całej ścieżki od konfiguracji klienta do procesu serwera.

Nazwa serwera, instancja i sposób wyboru portu

Połączenie z SQL Server może wskazywać instancję domyślną albo instancję nazwaną. Przykładowe formaty adresu to NAZWA-KOMPUTERA dla instancji domyślnej oraz NAZWA-KOMPUTERA\SQLEXPRESS dla instancji nazwanej. W środowisku lokalnym spotyka się także zapis localhost, nazwę hosta lub adres IPv4. Błąd powstaje między innymi wtedy, gdy aplikacja odwołuje się do nieistniejącej nazwy komputera, niewłaściwej nazwy instancji albo do instancji, która została usunięta lub zmieniona podczas instalacji.

Instancja domyślna SQL Server zwykle korzysta z portu TCP 1433, ale administrator może skonfigurować inny port. Instancje nazwane często używają portów dynamicznych, dlatego sam adres komputera nie zawsze wystarcza do ustalenia punktu połączenia. Przy zapisie zawierającym nazwę instancji klient może korzystać z usługi SQL Server Browser, która używa protokołu UDP na porcie 1434 do wskazania portu właściwej instancji. Alternatywą jest podanie konkretnego portu w adresie, na przykład NAZWA-KOMPUTERA,51433, jeżeli właśnie taki port został skonfigurowany dla SQL Server.

Sprawdzenie usługi, protokołów i zapory

Pierwszym krokiem jest potwierdzenie, że odpowiednia usługa SQL Server działa. Nazwa usługi zależy od instancji: dla instancji domyślnej jest to zwykle MSSQLSERVER, a dla instancji nazwanej nazwa ma postać MSSQL$NAZWA_INSTANCJI. Jeżeli usługa jest zatrzymana, klient nie otrzyma połączenia niezależnie od poprawności hasła. Warto również sprawdzić, czy aplikacja odwołuje się do tej samej instancji, która faktycznie działa w systemie.

W SQL Server Configuration Manager należy zweryfikować, czy dla danej instancji włączony jest protokół TCP/IP. Włączenie protokołu wymaga ponownego uruchomienia usługi SQL Server. Samo włączenie TCP/IP nie otwiera jeszcze dostępu przez sieć, ponieważ reguły zapory systemu Windows muszą dopuszczać ruch na porcie używanym przez instancję. Dla połączeń do instancji nazwanej trzeba dodatkowo uwzględnić sposób odnajdywania portu: działającą usługę SQL Server Browser albo jawnie podany port TCP.

Podstawową dostępność portu można sprawdzić z komputera klienta poleceniem Test-NetConnection NAZWA-KOMPUTERA -Port 1433, ale wynik ma sens tylko wtedy, gdy instancja rzeczywiście nasłuchuje na porcie 1433. Dla innego portu należy podać skonfigurowaną wartość. Test potwierdza możliwość zestawienia połączenia TCP z danym portem; nie potwierdza poprawności loginu, hasła, uprawnień ani działania konkretnego zapytania. Jeżeli test nie przechodzi, należy szukać przyczyny w adresie, trasie sieciowej, nasłuchu SQL Server lub zaporze.

Rozdzielenie problemu sieciowego od uwierzytelniania

W diagnostyce należy oddzielić Error 40 od błędów pojawiających się po dotarciu klienta do serwera. Jeżeli SQL Server odrzuca login lub hasło, komunikat zwykle dotyczy nieudanej próby logowania, a nie niemożności otwarcia połączenia. Podobnie brak uprawnień do konkretnej bazy danych jest innym etapem obsługi żądania. Error 40 wskazuje przede wszystkim na problem z odnalezieniem instancji albo nawiązaniem kanału komunikacyjnego, dlatego zmiana hasła bez sprawdzenia adresu i portu zazwyczaj nie rozwiązuje przyczyny.

Do kontrolnego testu można użyć narzędzia sqlcmd, wskazując serwer i instancję przez parametr -S, na przykład sqlcmd -S NAZWA-KOMPUTERA\SQLEXPRESS. Jeżeli połączenie wymaga wskazania portu, stosuje się zapis sqlcmd -S tcp:NAZWA-KOMPUTERA,51433. Taki test pomaga ustalić, czy problem dotyczy samej aplikacji, czy całego klienta SQL Server. Przy analizie trzeba zachować zgodność z rzeczywistą konfiguracją: nazwa instancji, protokół, port i metoda uwierzytelniania muszą odpowiadać ustawieniom SQL Server. Dopiero po potwierdzeniu łączności warto przejść do sprawdzania loginu, uprawnień i konfiguracji bazy wskazanej przez aplikację.