2013-07-11 11 views
7

Ich sehe die folgende Fehlermeldung beim Versuch, eine DB-Verbindung zu öffnen aus meiner C# -Anwendung. Ich realisiere, dass dieser Fehler wahrscheinlich schon bei 100 von Fragen aufgetreten ist. In diesem Szenario wird jedoch der Fehler zeigt sich nur auf # apps C auf meinem speziellen Desktop-PC läuft. Ich habe das Internet über Google und innerhalb dieser Website durchforstet, aber ich kann keine Lösung finden.SqlConnection auf Named Pipes steckte

ERROR:

„Ein netzwerkbezogener oder instanzspezifischer Fehler beim Herstellen einer Verbindung mit SQL Server Der Server wurde nicht gefunden oder war nicht erreichbar Überprüfen Sie, dass der Instanzname richtig ist und dass SQL Server.. so konfiguriert ist, Remote-Verbindungen zu ermöglichen. (Anbieter: Named Pipes-Anbieter, Fehler: 40 - keine Verbindung zu SQL Server öffnen kann)“

WARUM Dieses Szenario ist einzigartig:

ich in der Lage bin zu der SQL verbinden Server von SQL Server Management Studio (SSMS). Diese Anwendung auf einem anderen Computer arbeitet und in der Lage, von dort aus eine Verbindung mit dem SQL-Server herzustellen. Dieses Fehlerszenario ist also spezifisch für C# -Anwendungen, die auf meinem speziellen Desktop-PC ausgeführt werden. Andere Apps funktionieren (SSMS). Andere PCs arbeiten.

Wenn ich mit Wireshark „den Draht schnuppern“, die Spur zeigt mir, dass mein App über NamedPipes zu verbinden versucht, (d \ Server \ IPC $). Ich kann es anscheinend nicht zwingen, TCP/IP zu benutzen.

THINGS ich versucht habe:

  • Re-installed.NET Rahmen
  • Re-Installation von Visual Studio (C# - Express-Version 2010)
  • einen Alias ​​innerhalb cliconfg.exe Erstellt.

Gibt es etwas, was ich verpasst?

Hier sind Verbindungszeichenfolgen Ich habe versucht ...

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> 

Hier ist der Code-Schnipsel:

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

Setzen Sie den 'tcp:' auch für die 'Datenquelle' ein. Hard Code die Verbindungszeichenfolge in den C# Quellcode. Ihr wireshark-Debugging war sehr gut, weil es zeigt, dass es tcp nicht verwendet. – usr

+0

Danke für die schnelle Antwort @ usr. Mann .. ihr seid SCHNELL! Ich habe versucht "Datenquelle = TCP: ; Erster Katalog = HIE; Integrierte Sicherheit = True" und "Datenquelle = TCP: 10.240.11.81; Erster Katalog = HIE; Integrierte Sicherheit = True" und bekam neue Nachrichten: (Provider: TCP Provider, Fehler: 0 - Bei einer Datenbanksuche ist ein nicht behebbarer Fehler aufgetreten.) Und (Provider: TCP Provider, Fehler: 0 - Ein ungültiges Argument wurde angegeben.) Google gab mir zu diesen Fehlermeldungen nichts. Die "HIE" -Datenbank existiert auf dem Server. –

+0

Das ist verrückt. Der Fehler weist laut Google auf sehr seltsame Zustände hin. Können Sie den SQL Server über diese IP und den Port 1433 telnet? Wird die App als Administrator ausgeführt? Deaktivieren Sie UAC oder laufen Sie bitte erhöht. Bitte führen Sie Wireshark erneut aus. Was ist das? – usr

Antwort

0

entweder neu definieren Ihre Datenquelle wie usr Kommentar vorgeschlagen, oder Ihren SQL Server konfigurieren TCP-Verbindungen zulassen (Warum würden Sie TCP-Verbindungen nicht zulassen?).

Hier ist der Link TCP auf dem SQL-Server zu aktivieren (Die akzeptierte Antwort ist, wo Sie wollen, betrachten):

Enable remote connections for SQL Server Express 2012

+0

Die Client-Bibliothek verwendet laut Wireshark nicht einmal TCP. Der TCP-Endpunkt des Servers kann nicht das Problem sein. – usr

+0

@ usr Seltsam. Ich hatte diesen Fehler zuvor und ich habe es immer gelöst, indem ich den SQL Server richtig konfigurierte. –

+0

@usr Schauen Sie sich einfach den Link bitte an. Der andere Benutzer hatte genau das gleiche Problem und offenbar wurde es durch eine ordnungsgemäße Konfiguration des SQL Servers behoben. –

1

Das wahrscheinlichste Szenario ist, dass die Windows-Firewall ist der SQL Server blockieren Kommunikation. Von MSDN (ein Artikel über Named Pipes, aber relevant dennoch):

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.

Ein weiteres Szenario ist, dass die Client-Konfiguration auf dem lokalen Computer nicht richtig konfiguriert ist. Aus der Sicht Aufforderung können Sie cliconfg (die SQL Server Client Configuration Utility) auszuführen, um die aktivierten Protokolle und die Aliasnamen, um zu sehen, die für die Protokolle verwendet werden.

+0

Ja.Gebissen worden durch Port 445, der einige Male geschlossen wird und jedes Mal scheint eine Epiphanie zu nehmen, um zu realisieren, dass die Brandmauer Aktualisierung benötigt. –

+0

Dies erklärt nicht den ersten Fehler (keine TCP-Verbindung wurde sogar versucht). Zweitens sehe ich keine Beziehung zu den neuen Fehlermeldungen, die das OP erhält. Es ist nicht wie "Verbindung abgelehnt" oder so ähnlich. – usr

+0

Ich habe Firewall und cliconfg Probleme angesprochen. Es ist kein Firewall-Problem - als SSMS auf meinem Rechner (wo mein Programm keine Verbindung herstellen kann) ist es möglich, eine Verbindung zum SQL-Server herzustellen (es ist Remote, nicht auf meiner Box). ADO.NET schien die cliconfg-Einstellungen nicht zu verwenden. Ich musste den TCP-Provider (Network Library = DBMSSOCN oder Data Source = TCP: HHVSVTSQL01) explizit benennen, um ADO.NET zur Verwendung zu bringen. Aber ich fing an, eine andere Fehlermeldung zu erhalten, ohne dass Verkehr auf dem Draht auftauchte. –

0

Führen Sie Ihren Code von der lokalen Festplatte oder einem Netzlaufwerk aus? Ich habe ein sehr ähnliches Problem festgestellt, bei dem mein Netzlaufwerk in .Net nicht vertrauenswürdig war. Aus diesem Grund sind meine Verbindungen fehlgeschlagen.