wieder Mal Connect string

[MartinHan]

Hi,

so langsam klärt sich alles...nur manchmal gibt es noch unerklärliche Fehler.
Mit diesem connect string hatte ich mich schon mal aus Access an der Ms Db angemdeldet:

provider=MSOLEDBSQL.1;Persist Security Info=False;User ID=<>;PWD=<>;database=DbAdcProduktionProd;server=192.168.178.173\SQLEXPRESS;

Plötzlich klappt die Verbindeung nicht mehr.
Die DB ist up and running...

Jemand eine Idee?

Danke Martin

[PhilS]

Es fehlt hier etwas Kontext.
Ist der Connection-String für eine ADO-Verbindung im VBA-Code?
Dann sollte es eigentlich so funktionieren. Evtl. tausch mal User ID durch UID aus.

Wenn der Connection-String für eine Pass-Through-Abfrage oder verknüpfte Tabelle sein soll, funktioniert das prinzipiell nicht, weil dafür nur ODBC möglich ist.

[MartinHan]

Ich danke dir für deine Antwort...

Aber werde dir morgen mit frischem Hirn antworten!

Martin

[MartinHan]

Hi,

ich denke, es hat mit Access nichts zu tun. Ich kann die DB über ssms auch nicht erreichen.
Ich vermute mal im Umfeld Virenscanner oder so was.

Aber trotzdem danke für die Antwort.

Martin

[MartinHan]

Hi,

ich kann jetzt die DB wieder mit dem SSMS erreichen, es fehlte wohl eine Regel in der Windows Firewall (1433) und Kaspersky ist jetzt weg...

Aber der Connectstr aus Access heraus scheint noch falsch zu sein oder es fehlen noch andere Einstellungen:

SSMS: AdcSqlServer

Verbindung klappt...

Connectstr im Access (gleiches Ergebnis mit UID):

provider=MSOLEDBSQL.1;Persist Security Info=False;User ID=<user>;PWD=<pw>;database=DbAdcProduktionProd;server=AdcSqlServer;

Die Fehlermeldung ist, das eine ein Verbindung über named pipe nicht herstellen kann:

Named Pipes Connection. Could not open a connection to SQL Server(2).

Im SSMS klappt auch diese Angabe:

AdcSqlServer\SQLEXPRESS,1433

Connectstr:

provider=MSOLEDBSQL.1;Persist Security Info=False;UID=<user>;PWD=<>;database=DbAdcProduktionProd;server=AdcSqlServer\SQLEXPRESS,1433;

Dann kommt die Meldung TCP provider, der Wartevporgang wurde abgebrochen.

Es kann doch jetzt nur noch ein kleiner Schritt sein...

Danke für Hilfe

[PhilS]

Erlaubt denn dein Server Verbindungen über TCP/IP?
Das könntest du im SSMS testen, wenn du unter Optionen als Netzwerkprotokoll explizit TCP/IP einstellst.

Wenn TCP/IP grundsätzlich erlaubt ist, aber deine Verbindung trotzdem Named Pipes nutzen will, kannst du das Netzwerkprotokoll auch explizit angeben. Beispiel für TCP/IP:
provider=MSOLEDBSQL.1;Persist Security Info=False;UID=<user>;PWD=<>;database=DbAdcProduktionProd;server=AdcSqlServer\SQLEXPRESS,1433;Network= dbmssocn;
 

[MartinHan]

Ich habe noch nicht gefunden, wo man das im SSMS einstellt...
Ich habe den 1433 im Sql Configuration Manager eingestellt und TCP/IP aktiviert, ebenso named Pipes.

Ist es das was du meinst?
Aber auch mit diesem Zusatz bleibt der Fehler der gleiche...

[MartinHan]

Eigenschaften von TCP/IP
aktiviert ja
alle überwachen nein

TPAdresse:
IP3
aktiv ja
aktiviert ja
Dynamische ICPports: 64734
IP adresse .....
TCPport 1433

So steht es unter Protokolle für SQL Express

[MartinHan]

Hi,

ich bitte um Entschuldigung, dass ich erst jetzt reagiere, ich war heute verhindert.
Aber das Problem besteht nach wie vor und ich verstehe es nicht.
Warum kann ich mit SSMS eine Verbindung herstellen, aber mit ACCESS nicht?

Ein Mysterium..

Martin

[Knobbi38]

Hallo Martin,

du solltest das TCP/IP Protokoll als Standard-Protokoll einstellen und dann vorübergehend die FW mal deaktivieren, um mögliche andere Fehlerquellen auszuschließen. Dann mit sqlcmd überprüfen, ob dein SQL-Server erreichbar ist:
https://learn.microsoft.com/de-de/sql/tools/sqlcmd/sqlcmd-use-utility?view=sql-server-ver16

Für Access kontrollierst du deinen Connectionstring anhand der Angaben von hier:
https://www.connectionstrings.com/sql-server/

Achtung: Access und dein Treiber müssen die gleiche Bitbreite haben, unabhängig vom SQL-Server!

Anschließend die Tests mit eingeschalteter FW wiederholen.

HTH

Gruß
Knobbi38

[MartinHan]

ok, werde ich testen.

Ein Unterschied ist mir noch beim Ping aufgefallen.

C:\Users\Martin>ping AdCsqlServer

Ping wird ausgeführt für AdCsqlServer.fritz.box [2a00:6020:b428:5000:d54d:2ac3:a689:8187] mit 32 Bytes Daten:
Antwort von 2a00:6020:b428:5000:d54d:2ac3:a689:8187: Zeit=1ms
Antwort von 2a00:6020:b428:5000:d54d:2ac3:a689:8187: Zeit=1ms
Antwort von 2a00:6020:b428:5000:d54d:2ac3:a689:8187: Zeit=1ms
Antwort von 2a00:6020:b428:5000:d54d:2ac3:a689:8187: Zeit=1ms

Ping-Statistik für 2a00:6020:b428:5000:d54d:2ac3:a689:8187:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 1ms, Maximum = 1ms, Mittelwert = 1ms

C:\Users\Martin>ping 10.250.250.23

Ping wird ausgeführt für 10.250.250.23 mit 32 Bytes Daten:
Antwort von 10.250.250.23: Bytes=32 Zeit=1ms TTL=128
Antwort von 10.250.250.23: Bytes=32 Zeit=1ms TTL=128
Antwort von 10.250.250.23: Bytes=32 Zeit=1ms TTL=128
Antwort von 10.250.250.23: Bytes=32 Zeit=1ms TTL=128

Ping-Statistik für 10.250.250.23:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 1ms, Maximum = 1ms, Mittelwert = 1ms

Im ersten Fall wird nur nach IPV6 aufgelöst...
Ich weiß nicht, ob das wichtig ist.

[Knobbi38]

Nein, das spielt dabei keine Rolle, weil die AuflösungErreichbarkeit ja funktioniert. Du kannst mit PING auch exklusiv nur mal das IPV4 Protokoll verwenden und schauen, ob dann der Name immer noch aufgelöst wird.

Nach deinen Angaben funktioniert die Verbindung ja per IPV4 und IPV6. Die Namensauflösung selber kannst du dann mit dem Kommando nslookup oder in der PowerShell mit Resolve-DnsName testen.

[PhilS]

Ich habe noch nicht gefunden, wo man das im SSMS einstellt...
Ich habe den 1433 im Sql Configuration Manager eingestellt und TCP/IP aktiviert, ebenso named Pipes.

Bei SSMS gibt es im Verbindungsdialog ein "Optionen" oder "Erweitert" Button oder Tab, der Zugriff auf die Konfiguration des Netzwerkprotokolls erlaubt.

Named Pipes als Netzwerkprotokoll basiert auf SMB und ist in nicht-AD-Domain bzw. gerouteten Netzwerken evtl. nicht verfügbar. Ich würde Named Pipes eher deaktivieren und mich auf TCP/IP konzentrieren.

Aber auch mit diesem Zusatz bleibt der Fehler der gleiche...

Bei meiner Ergänzung von ;Network=dbmssocn; im Connectionstring hatte sich oben ein unerwünschtes Leerzeichen eingeschlichen, dass evtl. verhindert, dass die richtige Netzwerkbibliothek verwendet wird. - Eine Fehlermeldung mit expliziten Bezug auf Named Pipes sollte nicht mehr auftreten, wenn TCP/IP verwendet wird.

Ansonsten schließe ich mich knobbi38's Hinweise an: Erstmal alle (auf dem Server, Client und ggfls. dazwischen) Firewalls vorübergehend zu Diagnosezwecken deaktivieren.

[MartinHan]

So, jetzt bin ich ein Stück weiter.

Es liegt eindeutig an der Firwalleinstellung auf dem Server.
Ich habe beide FW Client und Server FB ausgemacht: Verbindung geht.
Nur Client an: Verbindung klappt
Nur Server an: klappt nicht.

Ich schließe daraus messerscharf, das es an den Einstellungen auf dem Server liegen muss!

Schau ich mir jetzt mal an, wo der UNterschied der Einstellungen im Vergleich zum Client liegt.

[MartinHan]

Wenn ich auf dem Server bei Windows FW den Haken bei "Windows defender für private Netzwerke" ausschalte klappt die Verbindung.
Frage ist jetzt, brauche ich diesen Schutz und wenn ja, wie kann ich ihn einstellen?

Danke noch mal für die Hilfe!