2013-07-11 21 views
7

Podczas próby otwarcia połączenia DB z poziomu aplikacji C# widzę następujący błąd. Zdaję sobie sprawę, że ten błąd prawdopodobnie pojawił się już na 100 pytaniach. Jednak w tym scenariuszu błąd pojawia się tylko na działającym na na moim konkretnym komputerze stacjonarnym. Przeszukałem internet przez Google i na tej stronie, ale nie mogę znaleźć rozwiązania.SqlConnection utknął na nazwanych potokach

BŁĄD:

„Wystąpił błąd związanych z siecią lub specyficzne dla instancji podczas ustanawiania połączenia do serwera SQL Serwer nie został znaleziony lub nie był dostępny Sprawdź, czy nazwa instancji jest poprawny i że SQL Server.. jest skonfigurowany do umożliwienia połączeń zdalnych. (dostawca: Named Pipes Provider, błąd: 40 - nie można otworzyć połączenia do serwera SQL)”

DLACZEGO Ten scenariusz jest wyjątkowy:

jestem w stanie połączyć się z SQL serwer od Studio zarządzania serwerem SQL (SSMS). Ta aplikacja działa na innym komputerze i jest w stanie nawiązać stamtąd połączenie z serwerem SQL. Tak więc ten scenariusz błędu dotyczy aplikacji C# działających na moim komputerze stacjonarnym. Działają inne aplikacje (SSMS). Inne prace na komputerze.

Kiedy "powącham przewód" za pomocą WireSharka, ślad pokazuje mi, że moja aplikacja próbuje się połączyć przez NamedPipes (tj. \ Server \ IPC $). Nie mogę zmusić go do korzystania z protokołu TCP/IP.

Czego próbowałem:

  • Re-installed.NET ramowa
  • Re zainstalowane Visual Studio (C# - Express wersja 2010)
  • utworzony alias w Cliconfg.exe.

Czy jest coś, co przeoczyłem?

Oto parametry połączeń próbowałem ...

Data Source=<servername>;Initial Catalog=HIE;Integrated Security=true 
Server=tcp:10.240.11.81;Integrated Security=SSPI; database=HIE 
Data Source=10.240.11.81,1433;Network Library=DBMSSOCN;Initial Catalog=HIE;User ID=<SqlUserIdThatISetUpAsSysAdmin>;Password=<password> 

Oto fragment kodu:

_conn = new SqlConnection(); // _conn declared globally 
_conn.ConnectionString = <the connection string above>; 
_conn.Open(); 
+1

Umieść 'tcp:' również dla 'źródła danych'. Twardy kod ciąg połączenia do kodu źródłowego C#. Twoje debugowanie Wireshark było bardzo dobre, ponieważ pokazuje, że nie używa Tcp. – usr

+0

Dzięki za szybką odpowiedź @usr. Człowieku .. jesteście SZYBKO! Próbowałem "Data Source = TCP: ; Initial Catalog = HIE; Integrated Security = True" i "Data Source = TCP: 10.240.11.81; Initial Catalog = HIE; Integrated Security = True" i otrzymałem nowe wiadomości: (provider: TCP Dostawca, błąd: 0 - Wystąpił nieodwracalny błąd podczas wyszukiwania bazy danych.) Oraz (dostawca: Dostawca TCP, błąd: 0 - Podano nieprawidłowy argument.) Google nie udzielił mi żadnych informacji o tych komunikatach o błędach. Baza danych "HIE" istnieje na serwerze. –

+0

To jest szalone. Błąd wskazuje na bardzo dziwne warunki według Google. Czy możesz telnetować serwer SQL przy użyciu tego adresu IP i portu 1433? Czy aplikacja działa jako administrator? Wyłącz UAC lub uruchom podwyższone, proszę. Uruchom ponownie Wireshark. Co to oznacza? – usr

Odpowiedz

0

Albo przedefiniować źródła danych jak sugeruje komentarzu usr, albo skonfigurować SQL Server aby zezwolić na połączenia TCP (Dlaczego w ogóle nie zezwoliłbyś na połączenia TCP?).

Oto link, aby umożliwić TCP na SQL Server (Zaakceptowanych odpowiedź jest gdzie chcesz patrzeć):

Enable remote connections for SQL Server Express 2012

+0

Lib klienta nawet nie używa TCP zgodnie z Wireshark. Punkt końcowy TCP serwera nie może być problemem. – usr

+0

@@ Dziwne. Miałem ten błąd wcześniej i zawsze rozwiązałem go, poprawnie konfigurując SQL Server. –

+0

@usr Wystarczy spojrzeć na link, proszę. Inny użytkownik miał dokładnie ten sam problem i najwyraźniej został rozwiązany przez prawidłowe skonfigurowanie serwera SQL. –

1

Najbardziej prawdopodobnym scenariuszem jest to, że Zapora systemu Windows jest zablokowanie SQL Server komunikacja. Od MSDN (artykuł o nazwanych potoków, ale mimo to istotne):

Microsoft Windows XP Service Pack 2 enables Windows Firewall, which closes port 445 by default. Because Microsoft SQL Server communicates over port 445, you must reopen the port if SQL Server is configured to listen for incoming client connections using named pipes. For information on configuring a firewall, see "How to: Configure a Firewall for SQL Server Access" in SQL Server Books Online or review your firewall documentation.

Inny scenariusz jest taki, że konfiguracja klienta na komputerze lokalnym nie jest prawidłowo skonfigurowany. Po wyświetleniu monitu o uruchomienie można wykonać cliconfg (narzędzie konfiguracyjne klienta SQL Server), aby wyświetlić włączone protokoły i aliasy używane w protokołach.

+0

Tak.Został ugryziony przez port 445, który był zamykany kilka razy i za każdym razem zdaje się zdawać sobie sprawę z tego, że firewall wymaga aktualizacji. –

+0

Nie wyjaśnia to pierwszego błędu (nie podjęto nawet próby nawiązania połączenia TCP). Po drugie nie widzę związku z nowymi komunikatami o błędach, które otrzymuje PO. To nie jest jak "odmowa połączenia" lub coś podobnego. – usr

+0

Rozwiązałem problemy z firewallem i cliconfg. To nie jest problem z zaporą - jako SSMS na moim komputerze (gdzie mój program nie może się połączyć) jest w stanie połączyć się z serwerem SQL (jest zdalny, a nie na moim komputerze). ADO.NET nie korzystał z ustawień cliconfg. Musiałem jawnie nazwać dostawcę TCP (Network Library = DBMSSOCN lub Data Source = TCP: HHVSVTSQL01), aby ADO.NET mógł z niego korzystać. Ale zacząłem otrzymywać inny komunikat o błędzie, a na drucie nie wyświetlał się żaden ruch. –

0

Czy Twój kod jest wyłączony z dysku lokalnego lub dysku sieciowego? Napotkałem bardzo podobny problem, gdy mój dysk sieciowy nie był zaufany w .Net i dlatego moje połączenia się nie powiodły.

Powiązane problemy