SQLCMD -Server kann nur per Namen erreicht werden, nicht via IP

[fft]

Hallo Zusammen,

warum kann bei mir der lokale SQL Server nicht per IP sondern nur via Rechnername erreicht werden?
Das hier geht:

sqlcmd -S DETTE11L040\TEST

Das hier nicht:

sqlcmd -S 10.100.200.150\TEST

Ping auf

DETTE11L040

ergibt die IP

10.100.200.150

Ich habe Sever 2019 auf Win11enterprise installiert, Sqlcmd ist die Version15.0.2000.5 NT

Hat jemand eine Idee, woran das liegen könnte? Wenn ich was testen soll/ zu wenig Informationen geliefert habe, immer gerne her damit.

Grüße Georg

 

[SoDaTierchen]

Du hast Windows 11 Enterprise im Einsatz, bist also geschäftlich unterwegs - frag deine IT, die weiß das.

Falls du aus irgendwelchen Gründen doch selbst das Problem angehen möchtest, obwohl recht wenige Kenntnisse vorhanden sind: Installationen von MSSQL-Server haben in den Standardeinstellungen den Listener auf TCP/IP deaktiviert. Du kommst über den Rechnernamen ran, weil sqlcmd ungefragt auf Named Pipes setzt. Also TCP/IP aktivieren, ggf. noch eine Firewallausnahme für deine TEST-Instanz und den SQL Server Browser hinzufügen, schon geht es.

 

[=dantE=]

"Named Pipe" und "TCP/IP" im SQL Server Management unter Netzwerk prüfen.
Kann ja sein dass dort TCP/IP nicht enabled ist!

Edit: ... Zweiter

 

[SoDaTierchen]

Noch ein kleiner Nachtrag: Führe bitte ein Update aus, du nutzt einen ungepatchten SQL Server 2019. Da du vor hast, TCP/IP zu aktivieren, solltest du diesen aktuell halten. Momentan dürfte er ja noch nicht produktiv im Einsatz sein, du kannst also noch gefahrenfrei durchpatchen und neustarten. Die aktuelle Version lautet 15.0.4335.1

 

[TK-Shockwave]

Problem ist eher, du hast eine Named Instance..somit nicht mehr den Standard Port 1433 sondern einen High Port (Dyn. Port).
Bei der IP musst du dann den Port mitgeben, beim Namen löst der SQLBrowser das ganz noch auf.

 

[SoDaTierchen]

@TK-Shockwave : Der SQL-Serverbrowser kann das auch auflösen, wenn du die IP verwendest anstatt des Hostnamen. Du musst nur die Instanz korrekt benennen. Vorausgesetzt, der SQL Server Browser läuft.

Die manuelle Portvergabe ist kein Muss. Sie schadet auch nicht, aber ist in diesem Anwendungsfall nicht unbedingt notwendig und übersteigt hier glaube (noch) die Fähigkeiten unseres TE.

 

[TK-Shockwave]

bei High Port braucht es bei der IP den Port ..es geht nur bei den Standard Port. Da SQLCMD die SqlClient Klasse benützt und diese ist per default auf 1433. SQL Browser läuft per default nicht und ist auf "disabled"

Aber generell wäre interessant, zu sehen ob es klappt wenn er die IP und Port benützt.
Konnte dieses verhalten auch in einem schnell Test nachstellen.

 

[SoDaTierchen]

bei High Port braucht es bei der IP den Port ..es geht nur bei den Standard Port

Das kann ich weder sprachlich noch inhaltlich deuten. SQL verhält sich nicht anders, wenn man einen High Port oder einen Low Port benutzt. Wenn man weder Instanzname noch Port angibt, wird auf 1433 verbunden. Gibt man den Instanznamen an, wird der SQL Server Browser auf 1434 angefragt. Gibt man den Port an, wird sich dahin verbunden. Egal, ob High Port oder nicht. "SqlClient Klasse" klingt ziemlich erfunden, sqlcmd arbeitet mit ODBC. Hättest du hier eine Quelle zu dem Klassennamen? Hilft dem Thema nicht weiter, aber ein bisschen interessiert mich die Implementierung dann doch, falls du da mehr weißt als ich.

Der SQL Server Browser ist im Standard nicht auf Autostart eingestellt, das stimmt. Hier muss man den erst aktivieren. Das hätte ich deutlicher herausstellen können.
IP und Port sollte funktionieren, wenn die Firewall nicht dazwischenfunkt. Das ist ja das angedachte Verhalten.

 

[fft]

Danke für die hilfreichen Hinweise!

Kurzes Update, wenn unter Dienste\SQL Server-Browser läuft und unter SQL Server Configuration Manager\Server Netzwerk-Konfiguration TCP aktiviert wurde geht auch das ansprechen über IP.
Hier war nur Shared Memory aktiviert...

Ich glaube ich wollte so bei dem hier tun etwas anderes... (sorry dafür)
Ich habe bestehende Verbindungen auf den Server mit Programmen über ODBC und ich wollte diesen "Verbindungskanal" testen wollen.
Ich dachte ODBC geht immer über TCP1433, scheint aber nicht so zu sein, was wird denn hier genutzt?
Ich verbinde mich immer über den Microsoft ODBC Driver for SQL Server, Version 17.10.0005


By the way, das ist nur ein lokaler Testserver, der wird nie online gehen. Ich will mit dem nur Kundensysteme simulieren, wenn an diesere unser SW angebunden werden soll.

 

[fft]

Sollte ich dann einen neuen Thread öffnen?

 

[TK-Shockwave]

Das kann ich weder sprachlich noch inhaltlich deuten. SQL verhält sich nicht anders, wenn man einen High Port oder einen Low Port benutzt. Wenn man weder Instanzname noch Port angibt, wird auf 1433 verbunden. Gibt man den Instanznamen an, wird der SQL Server Browser auf 1434 angefragt. Gibt man den Port an, wird sich dahin verbunden. Egal, ob High Port oder nicht. "SqlClient Klasse" klingt ziemlich erfunden, sqlcmd arbeitet mit ODBC. Hättest du hier eine Quelle zu dem Klassennamen? Hilft dem Thema nicht weiter, aber ein bisschen interessiert mich die Implementierung dann doch, falls du da mehr weißt als ich.

Der SQL Server Browser ist im Standard nicht auf Autostart eingestellt, das stimmt. Hier muss man den erst aktivieren. Das hätte ich deutlicher herausstellen können.
IP und Port sollte funktionieren, wenn die Firewall nicht dazwischenfunkt. Das ist ja das angedachte Verhalten.

Erfunden ähm:
https://learn.microsoft.com/en-us/dotnet/api/system.data.sqlclient?view=dotnet-plat-ext-8.0

Wenn ich den SQL Browser nicht aktiv habe und einen High Port geht es nicht einfach so.
Du musst schon SQL Browser laufen haben, dann geht es - ansonsten brauchst den Port.
https://learn.microsoft.com/en-us/s...-on-a-specific-tcp-port?view=sql-server-ver16

@fft ja schau doch mal welchen Port dein Server hat wie o.g und trage in der ODBC Verbindung Server, Port ein und schau.

 

[fft]

ansonsten brauchst den Port.

Dh. um über TCP zu gehen müsse man dem Server einen festen Port vergeben?

a schau doch mal welchen Port dein Server hat wie o.g und trage in der ODBC Verbindung Server, Port ein und schau.

gar keinen? Kann das sein?

Ergänzung (29. November 2023)

Aber wie geht das dann über ODBC?

 

[morcego]

Nein du brauchst keinen festen Port, dafür ist ja der SQL Browser zuständig. Wenn ein Client anfragt, gibt der den aktuellen Port der Instanz zurück.
Wenn du im SQL Configuration Manager bei der Instanz TCP/IP aktiviert und die Instanz neugestartet hast, ist das tutti. Der SQL Browser Dienst sollte natürlich auch laufen.

Dann geht du in die "Windows Defender Firewall mit erweiterter Sicherheit" und legst zwei neue eingehende Regeln an:

• Neu > Port > UDP 1434 > Bereich Domäne, privat, öffentlich (was du brauchst > Name vergeben, speichern.
• Neu > Programm > die sqlservr.exe deiner Instanz angeben > Bereich Domäne,... > Name vergeben, speichern.

Die exe findet sich im binn Verzeichnis der Installation. Bsp SQL 2019: c:\Programme\Microsoft SQL Server\MSSQL15.INSTANZNAME\MSSQL\Binn

Und dann sollte das eigentlich egal ob ODBC, SMSS oder C# SqlClient per Server\Instanzname klappen.