[DBNETLIB][ConnectionOpen CreateFile (PreLoginHandshake()).]Allgemeiner Netzwerkfehler - Verbindung zu SQL-Datenbank in VB-script

Ich habe ein VB-Skript, welches eine Verbindung zu einer lokalen SQL-Datenbank zum abrufen eines Werts. Die exakt gleiche script läuft auf über 100 Server, aber ein paar von den Servern, die diesen Fehler verursachen:

[DBNETLIB][ConnectionOpen CreateFile (PreLoginHandshake()).]Allgemeiner Netzwerkfehler. Überprüfen Sie Ihre Netzwerk-Dokumentation

Hier ist der code, der ausgeführt wird:

Function GetPrimaryServerID
On Error Resume Next
Set objConnection = CreateObject("ADODB.Connection")
Set objRecordSet = CreateObject("ADODB.Recordset")
objConnection.Open "Provider=SQLOLEDB;Data Source=127.0.0.1;Initial Catalog=xxx;User ID=xxx;Password=xxx"
sqlquery = "SELECT ServerID FROM tblSettings"
objRecordSet.Open sqlquery,objConnection
objRecordSet.MoveFirst
GetPrimaryServerID = objRecordSet("ServerID")
objRecordSet.Close
objConnection.Close 
End Function

Tritt der Fehler in der 5. Zeile beim öffnen des connection string. Ich bin verwirrt, warum das Skript funktioniert auf fast allen Servern und nicht, nur eine Handvoll. Die Datenbank, die Sie herstellen, identisch ist, auf jedem server in Bezug auf Struktur, nur die Daten, die sich ändern.

InformationsquelleAutor VBscripter | 2009-12-07

  1. 2

    Behoben das problem, indem Sie Folgendes tun:
    Geöffnet SQL Server-Konfigurations-Manager, und ging auf Protokolle für MSSQLSERVER -> TCP/IP. In der 'IP-Adressen' - Schaltfläche, bemerkte ich, dass IP2 die Adresse 127.0.0.1 aktiv war, aber nicht aktiviert. Geändert, aktiviert und neu gestartet, SQL services. Mein VB-Skript nun erfolgreich öffnet eine Verbindung zu 127.0.0.1.

    InformationsquelleAutor VBscripter

  2. 0

    Könnte es scheitern, wenn die Datenbank nicht konfiguriert ist, hören Sie auf TCP/IP-Verkehr. Der Fehler "Named Pipes-Anbieter, Fehler: 0 - Kein Prozess ist am anderen Ende der Leitung." weist in diese Richtung.

    Können Sie testen, mit:

    telnet 127.0.0.1 1433

    Konfigurieren, auf dem der server lauscht, verwenden Sie "SQL Server-Netzwerkkonfiguration" für SQL Server 2000, oder "SQL Server Surface Area Configuration" für SQL Server 2005 und.

    ok habe ich gemacht der telnet-test und es ist fehlgeschlagen, konnte keine Verbindung hergestellt werden, auf port 1433. Die Server, SQL Server 2005 verwenden, die ich geöffnet habe, die SQL Server-Oberfläche Bereich Konfiguration, aber können Sie bitte beraten, wo ich gehen, um zu konfigurieren, in denen der server lauscht?
    klicken Sie auf Surface Area Configuration for Services and Connections, dann MSSQLSERVER -> Database Engine -> Remote Connections, und stellen Sie sicher, dass eine der Optionen mit TCP/IP aktiviert ist
    "lokale verbindungen und Remoteverbindungen" und "TCP/IP und named pipes" sind ausgewählt, aber ich kann immer noch keine Verbindung zu 127.0.0.1 durch management studio oder telnet auf 127.0.0.1 auf port 1433.
    Überprüfen Sie die Protokolle für eine Linie, die aussieht "wie SQL server überwacht auf <ip>: <port>" (sollte in der Nähe von Start) und stellen Sie sicher, dass es den port 1433 überwachen?
    Ich glaube, ich hab das problem gefunden. Ich öffnete den SQL Server-Konfigurations-Manager, und ging auf Protokolle für MSSQLSERVER -> TCP/IP. In der 'IP-Adressen' - Schaltfläche, bemerkte ich, dass IP2 die Adresse 127.0.0.1 aktiv war, aber nicht aktiviert. Es scheint beides zu sein, aktiv und aktiviert auf dem Server, arbeiten. Aber diese änderung erfordert Neustart von SQL-Dienste, also werde ich warten, bis nach Stunden zu testen.

    InformationsquelleAutor Andomar

  3. 0

    Es ist kein Datenbankfehler, sondern ein client-tools oder config-Fehler

    Dem fehlerhaften Server wahrscheinlich:

    • haben eine andere Ebene der SQL Server-install /enthält service pack)
    • konfiguriert sind, für die Windows-Authentifizierung nur
    • eine ältere MDAC (mit SQL Service pack, OS Service pack, etc)

    Edit:

    SQL-Server SSL-Verschlüsselung, server-Seite ist hier beschrieben. Und in KB 316898 zu

    • "Server-Seite" erfordert nur ein server-Zertifikat und alle verbindungen sind verschlüsselt
    • "client-Seite" erfordert client-CERT und ist optional, und nur für diesen client

    Bestimmte client-Bibliotheken (insbesondere MS JDBC) unterstützen das nicht.

    Wenn ich habe richtig erraten, müssen Sie entweder der client oder der server SSL-Verschlüsselung, basierend auf dem server (dein script agiert als client)

    Alle Server haben Windows 2003 R2 x64 SP2. Alle Server werden mithilfe von SQL Server 9.0.3042 64 bit. Dies umfasst die folgenden und Server Fehler. Ich habe doppelt überprüft Sie die ausfallenden Server, nur um sicherzugehen. Ich bin mir nicht sicher, wie Sie Sie zu überprüfen MDAC-version. Ich habe gerade bemerkt, dass auf dem Server Fehler, beim öffnen von SQL Server Management Studio, ich kann keine Verbindung zu 127.0.0.1, ich habe eine Verbindung zu dem server Namen. Aber auf jeden anderen server kann ich eine Verbindung zu 127.0.0.1.
    Dies ist der Fehler, wenn Sie versuchen, eine Verbindung zu 127.0.0.1 auf dem fehlerhaften Server über Management Studio: Eine Verbindung erfolgreich hergestellt wurde, mit dem server, aber dann ein Fehler ist aufgetreten, während die pre-login-handshake. Wenn eine Verbindung mit SQL Server 2005 kann dieser Fehler dadurch verursacht werden, dass die Standardeinstellungen von SQL Server keine Remoteverbindungen zulassen. (Anbieter: Named Pipes-Provider, error: 0 - Kein Prozess ist am anderen Ende der Leitung.) (Microsoft SQL Server, Fehler: 233)
    können Sie ping 127.0.0.1? sind diese server konfiguriert encrpytion?
    ja, ich kann ping 127.0.0.1, und die windows-firewall deaktiviert ist. Kann Sie bitte sein spezifischer über Ihre Verschlüsselung Frage?

    InformationsquelleAutor gbn

  4. 0

    Kann es auch unpassende Anrufe zu WSAStartup und WSACleanup. Wenn Sie anrufen WSACleanup zu oft, dann sockets aufhören zu arbeiten. Und der SQL-client wird auch brechen - das ist normalerweise der Fall für die remote-DB-Server (im Gegensatz zu lokalen Instanzen Zugriff über named pipes etc.).

    InformationsquelleAutor E. van Putten

  5. -1

    1. Versuchen, deaktivieren Sie die WPF und das sollte das problem lösen (Systemsteuerung -> Windows-Firewall).

    2. Wenn nicht, dann können Sie auch aufhören, den Dienst für die firewall (aus dem Dienste.msc --> Windows-personal-firewall)

    Es würde dazu beitragen, Ihre Antwort viel zu erklären, warum Sie denken, dass die Windows-Firewall könnte Schuld hier.

    InformationsquelleAutor Varun Gautam

Schreibe einen Kommentar