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
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.
Ich danke dir für deine Antwort...
Aber werde dir morgen mit frischem Hirn antworten!
Martin
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
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
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;
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...
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
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
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 (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/ (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
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.
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.
Zitat von: MartinHan am Oktober 01, 2024, 13:54:40Ich 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.
Zitat von: MartinHan am Oktober 01, 2024, 13:54:40Aber 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.
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.
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!
Zitat von: MartinHan am Oktober 02, 2024, 13:53:21Frage ist jetzt, brauche ich diesen Schutz und wenn ja, wie kann ich ihn einstellen?
Es wäre fahrlässig leichtfertig auf diese generelle Frage eine pauschale Antwort ohne Risikoanalyse und Sicherheitskonzept zu geben.
Ich würde die Firewall aktiviert lassen und nur eingehende TCP/IP Verbindungen auf Port 1433 erlauben. Wenn der Server auch aus dem Internet erreichbar ist, würde ich diese Regel auf Verbindungen aus dem lokalen Netzwerk beschränken.
Das lässt sich relative einfach konfigurieren, wenn man die Windows Firewall Anwendung startet und "Neue Regel" anwählt (In der Task-Pane auf der rechten Seite) und dann als Typ entweder "Port" oder "Benutzerdefiniert" auswählt.
Hallo Martin,
wie Phil schon geschrieben hat, kann das mit der Management Console eingestellt werden:
-> Windows-Taste + {R} -> wf.msc und mit {STRG}{SHIFT}{ENTER} bestätigen.
Alternativ gibt es auf diesen Seiten Hinweise darauf, wie man das per PowerShell-Script einstellen kann:
https://learn.microsoft.com/de-de/sql/sql-server/install/configure-the-windows-firewall-to-allow-sql-server-access?view=sql-server-ver16 (https://learn.microsoft.com/de-de/sql/sql-server/install/configure-the-windows-firewall-to-allow-sql-server-access?view=sql-server-ver16)
https://www.der-windows-papst.de/2019/11/10/sql-server-ports-per-powershell-konfigurieren/ (https://www.der-windows-papst.de/2019/11/10/sql-server-ports-per-powershell-konfigurieren/)
... was ich eigentlich bevorzuge.
Gruß
Ulrich
Nachtrag:
Hier noch ein Tip, wenn man dynamischen Ports nutzt:
https://learn.microsoft.com/de-de/sql/database-engine/configure-windows/configure-a-windows-firewall-for-database-engine-access?view=sql-server-ver16#open-access-to-sql-server-when-using-dynamic-ports (https://learn.microsoft.com/de-de/sql/database-engine/configure-windows/configure-a-windows-firewall-for-database-engine-access?view=sql-server-ver16#open-access-to-sql-server-when-using-dynamic-ports)
Port 1433 hatte ich ja schon eingestellt, damit ging ja die Verbindung mit SSMS, nur nicht mit ACCESS.
Der Server ist aus dem Internet nicht erreichbar! Wenn dem so wäre, gebe ich dir natürlich recht, wäre das grob fahrlässig.
Ok, dann schau ich mir nochmal genau die Einstellungen an. Aber ich bin froh, das ich genau weiß, wo ich etwas ändern muss.
Danke für die Links!
Martin
Hi,
alles läuft wunderbar!
Nach einem Windows-update lief gar nix mehr.
Ich habe dann die gesamte db-Installation neu gemacht, den Port eingerichtet, komplett neue Instanz...
Uns alles läuft wunderbar, auch von Remote und mit eingeschalteter FW.
Ich bin wunschlos glücklich!
Bis dum nächsten Problem!
Martin