| Termin | Definicja |
|---|---|
| Włączenie Named Pipes | Włączenie Named Pipes umożliwia komunikację z instancją tym protokołem, przydatnym głównie w sieci lokalnej. Rola Named Pipes w komunikacji z SQL ServerNamed Pipes to protokół sieciowy obsługiwany przez aparat Microsoft SQL Server. Po jego włączeniu klient może nawiązać połączenie z konkretną instancją SQL Server za pośrednictwem nazwanej potoki systemu Windows, zamiast korzystać z protokołu TCP/IP. Mechanizm może działać zarówno przy połączeniach lokalnych, jak i między komputerami w sieci Windows, jednak jego praktyczna przydatność zależy od konfiguracji systemu, zapory sieciowej oraz sposobu rozpoznawania instancji. W SQL Server protokół Named Pipes jest jednym z ustawień sieciowych przypisanych do instancji, a nie globalnym przełącznikiem dla wszystkich usług. W SQL Server Configuration Manager konfigurację otwiera się w gałęzi SQL Server Network Configuration, następnie Protocols for <nazwa_instancji>. Pozycja Named Pipes ma stan Enabled albo Disabled. Zmiana tego ustawienia dotyczy wybranej instancji Database Engine, dlatego w środowisku z kilkoma instancjami każdą z nich trzeba sprawdzić oddzielnie. Włączenie protokołu i ponowne uruchomienie instancjiAby włączyć Named Pipes, należy uruchomić SQL Server Configuration Manager z uprawnieniami administracyjnymi, przejść do protokołów sieciowych właściwej instancji i otworzyć właściwości pozycji Named Pipes. Ustawienie Enabled aktywuje protokół w konfiguracji instancji. Samo zapisanie zmiany nie powoduje jednak natychmiastowego przeładowania stosu komunikacyjnego działającego procesu. Po zmianie SQL Server zwykle wymaga ponownego uruchomienia usługi Database Engine, aby instancja zaczęła nasłuchiwać również za pomocą Named Pipes. Restart usługi należy zaplanować, ponieważ rozłącza aktywne sesje i przerywa wykonywane połączenia z bazami danych. W konfiguracji produkcyjnej przed ponownym uruchomieniem trzeba sprawdzić nazwę instancji, zależne usługi oraz sposób łączenia aplikacji. Po restarcie stan usługi można zweryfikować w SQL Server Configuration Manager albo w konsoli usług Windows. Włączenie protokołu nie oznacza jeszcze, że każde połączenie zdalne będzie działało: klient musi używać sterownika obsługującego SQL Server Named Pipes, a system musi umożliwiać przejście ruchu wymaganego przez ten mechanizm. Nazwa potoki, klient i diagnostyka połączeniaPołączenie z instancją SQL Server może zostać wskazane przez nazwę serwera i instancji, na przykład w formie Przy instancjach nazwanych problemem może być także odnalezienie właściwej instancji przez klienta. Jeżeli aplikacja korzysta z formatu nazwa-serwera\instancja, do ustalenia informacji o instancji może być potrzebna usługa SQL Server Browser. Gdy połączenie nie działa, warto sprawdzić kolejno: czy Named Pipes jest włączone dla właściwej instancji, czy Database Engine został uruchomiony ponownie, czy klient nie wymusza TCP/IP, czy sterownik wskazuje poprawny serwer oraz czy zapora Windows i zasady sieciowe zezwalają na komunikację. Błąd „provider: Named Pipes Provider” nie przesądza samodzielnie o jednej przyczynie; może oznaczać brak dostępności serwera, błędną nazwę instancji, niedziałającą usługę albo blokadę połączenia. Dobór protokołu w środowisku SQL ServerWłączenie Named Pipes nie wyłącza TCP/IP ani Shared Memory. SQL Server może mieć aktywnych kilka protokołów, a kolejność preferencji klienta wpływa na sposób zestawienia połączenia. Shared Memory służy do komunikacji lokalnej na tym samym komputerze, natomiast Named Pipes i TCP/IP są przeznaczone również do komunikacji sieciowej. Jeżeli aplikacja ma działać na wielu stanowiskach, trzeba przetestować połączenie z rzeczywistego komputera klienckiego, ponieważ poprawne połączenie lokalne nie potwierdza dostępności usługi w sieci. Named Pipes jest elementem konfiguracji transportu SQL Server, a nie metodą naprawiania problemów z uwierzytelnianiem, uprawnieniami do baz ani uszkodzeniem danych. Protokół może pomóc w środowisku opartym na starszych aplikacjach lub określonych wymaganiach sieci Windows, ale jego aktywacja powinna wynikać z potrzeb konkretnej instancji i klienta. Podczas diagnostyki należy odróżnić błąd warstwy transportowej od błędu logowania: jeśli klient nie dociera do serwera, sprawdza się usługę, nazwę endpointu i zaporę; jeśli połączenie jest ustanowione, analizuje się konto, metodę uwierzytelniania oraz uprawnienia SQL Server. |