Wie bekomme ich diese SQL Server ODBC-Verbindung zum Laufen?

Hinweis: Ich habe offensichtlich die Servernamen und IPs in fiktive geändert.

Hier ist was los ist. Ich habe einen Server, den ich anrufe und auf MYSERVERdem Microsoft SQL Server Express 2005 ausgeführt wird. Auf diesem Server selbst ist eine ODBC-Verbindung eingerichtet, die auf sich selbst zeigt, und die funktioniert bereits einwandfrei. Ich melde mich mit der SQL Server-Authentifizierung an (nicht mit der Windows-Authentifizierung). Die Einrichtung sieht folgendermaßen aus:

Wie gesagt, das funktioniert. Aber als nächstes habe ich einen anderen Computer, der sich in einer völlig anderen Domäne befindet / nicht im Intranet, der auf denselben SQL Server zugreifen muss, der auf MYSERVER gehostet wird. Da es sich um eine andere Domain handelt, wird der Name "MYSERVER" nicht erkannt. Ich muss es auf die IP-Adresse von MYSERVER verweisen, von der wir sagen, dass sie 123.456.789.012 ist. Aber die ODBC-Verbindung scheint dort nicht zu funktionieren. Ich habe versucht, es so einzurichten:

Das geht nicht. Wenn ich den Benutzernamen und das Passwort eingebe und auf "Weiter" drücke, bleibt das Programm für 10 bis 20 Sekunden stehen und kehrt schließlich mit der folgenden Fehlermeldung zurück:

Connection failed:
SQLState: '01000'
SQL Server Error: 1326
[Microsoft][ODBC SQL Server Driver][DBNETLIB]ConnectionOpen (Connect()).
Connection failed:
SQLState: '08001'
SQL Server Error: 17
[Microsoft][ODBC SQL Server Driver][DBNETLIB]SQL Server does not exist or access denied.

Wenn ich das Gleiche versuche, aber den "Server" von " 123.456.789.012\SQLEXPRESSNur alt " ändere 123.456.789.012, erhalte ich einen anderen Fehler:

Connection failed:
SQLState: '01000'
SQL Server Error: 14
[Microsoft][ODBC SQL Server Driver][DBNETLIB]ConnectionOpen (Invalid Instance()).
Connection failed:
SQLState: '08001'
SQL Server Error: 14
[Microsoft][ODBC SQL Server Driver][DBNETLIB]Invalid connection.

Jetzt weiß ich, was du denkst. Sie könnten denken: "Sie haben wahrscheinlich nicht die Firewall für Port 1433 geöffnet, Dummy." Ansonsten habe ich Folgendes überprüft, da ich Folgendes erfolgreich ausführen kann:

telnet 123.456.789.012 1433

... von der Kommandozeile alles was ich will. Ich bin mir also nicht sicher, was ich tun soll. Ich weiß , dass die SQL Server vorhanden ist , funktioniert, und eine ODBC - Verbindung kann richtig eingerichtet werden; Ich bin mir nur nicht sicher, woran es liegt, dass meine Verbindungseinstellungen diese Fehler auslösen. Basierend auf dem zuletzt genannten Fehler scheint es, dass eine Verbindung zum Server hergestellt werden kann, die Instanz jedoch nicht gefunden werden kann (da ich zu diesem Zeitpunkt keine angegeben habe). Bedeutet das, dass ich nur eine andere Syntax verwenden muss, um die IP zusammen mit einem Instanznamen anzugeben? Was mache ich? Danke im Voraus.

Named Pipes und TCIP-Protokolle für SQL Server 2005 sind standardmäßig deaktiviert. Haben Sie sie unter "SQL Server-Konfigurationsmanager" aktiviert? Sie finden die Protokolle in der SQL Server-Netzwerkkonfiguration und unter SQL Native Client xx-Konfiguration.

Die Verbindung auf dem Server selbst funktioniert dank des "Shared Memory" -Protokolls.

Haben Sie den SQL Server-Browserdienst gemäß So konfigurieren Sie SQL Server 2005 für das Zulassen von Remoteverbindungen :

Wenn Sie SQL Server 2005 unter Verwendung eines Instanznamens ausführen und keine bestimmte TCP / IP-Portnummer in Ihrer Verbindungszeichenfolge verwenden, müssen Sie den SQL Server-Browserdienst aktivieren, um Remoteverbindungen zuzulassen. Beispielsweise wird SQL Server 2005 Express mit dem Standardinstanznamen Computername \ SQLEXPRESS installiert.

Dieser Thread behebt die gleiche Fehlermeldung für mich, wenn ich Access verwende, um eine Verbindung zu einem MSSQL 2008-Server herzustellen. MSSQL 2005 und frühere Versionen funktionierten problemlos, wenn nur der Computername in der Verbindungszeichenfolge verwendet wurde. Bei der Aktualisierung der Instanz auf 2008 musste ich jedoch die Verbindungszeichenfolge in Access to the full form ändern:

servername\instancename,portnumber

Ich hatte das gleiche Problem und konnte es beheben, indem ich auch den SQL-Treiber in den SQL Native Client-Treiber änderte. Das war komisch, denn in meinem Fall hat das jahrelang gut funktioniert und dann einfach aufgehört zu arbeiten. Ich vermute, dass dies etwas in der Richtung ist, in der der Treiber beschädigt ist. Vielleicht hilft eine Neuinstallation von MDAC, aber im Moment bin ich froh, dass es überhaupt funktioniert!

Würde es den Servernamen erkennen, wenn es voll qualifiziert wäre? Wenn es MYSERVER.domain.com wäre? Wir mussten das mit SQL Server tun, wenn wir eine Verbindung von einer anderen Domäne aus herstellten. Wenn Sie beim Testen der Datenquelle eine Verbindung zum ODBC-System-DSN herstellen können, machen Sie Fortschritte. Wenn die Verbindung im ODBC-Setup nicht hergestellt werden kann, müssen Sie dies zuerst beheben.

Verwenden Sie Named Pipes oder TCP für die ODBC-Verbindung, die funktioniert? Ist TCP aktiviert?

Stellen Sie sicher, dass für den SQL-Server Remote-TCP-Verbindungen aktiviert sind.

Nur ein wilder Schuss hier, aber was passiert, wenn Sie einen doppelten Backslash vor den Servernamen oder die IP-Adresse setzen? Es scheint mir nur, dass es normalerweise für die meisten anderen Windows / Microsoft-Verbindungen erforderlich ist.

Ich hatte ein ähnliches Problem. In meinem Fall konfiguriert ein anderer SW die ODBC-Einstellung so, dass ich den Treiber nicht ändern kann. Ich habe meinen Fall so gelöst:

1. Legen Sie die TCP / IP-Einstellungen für den Server fest, um den Port 1433 zu verwenden
2. Geben Sie auf dem Client die Serveradresse wie folgt ein: 192.168.1.5,1433 (kein Instanzname)

Dann fing es an zu arbeiten. Client-Betriebssystem: Win7 x64 Treiber: sqlsrv32.dll

Für was es wert ist, fing ich an, diesen Fehler auf einer Verbindung zu erhalten, die vorher gearbeitet hatte. Es stellte sich heraus, dass der MSSQL $ SQLEXPRESS-Dienst irgendwie gestoppt wurde. Durch einen Neustart wurde das Problem behoben.

Ich hatte auch dieses Problem und es war so einfach: Der als primärer DNS-Server für diesen Server aufgeführte Server wurde entfernt, und die App konnte den Namen des SQL-Servers im Netzwerk nicht mehr korrekt auflösen. Alles begann sofort wieder zu funktionieren, als ich den lokalen DNS-Server auf einen funktionierenden korrigierte.