MSSQL-Verbindung - mal gehts, mal nicht

[gmc616]

Hallo DP-Gemeinde,

ich habe ein Problem, welches nicht direkt etwas mit der Programmierung zu tun hat, aber dennoch mit den MSSQL-Server-2008. Falls das Thema besser in ein anderes Board gehört, bitte verschieben ;-)

Ich haben einen Win-2012-Server mit installiertem MSSQL-Server-2008.

Von einer Win-Workstation (Win7/XP/2000 egal) verbindet sich meine Anwendung per TADO über den selbst gebauten ConnectionString

Code:

Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;User ID="";Initial Catalog="MyBase";Data Source="w2k12data\sql2008";Initial File Name="";Server SPN=""

auf den MSSQL-Server.

Das Problem: "Mal gehts, mal nicht", oder besser "Gestern gings, heute nicht mehr".

Baut man eine Verbindung per ODBC-Datenquellen-Administrator auf, funktioniert das ganze im gleichen Stiel.
Weißt man der ODBC-Verbindung einen festen Port zu gehts wieder ... bis zum nächsten mal, dann hilft es wieder, die dynamische Ports zu verwenden. Das gleiche Verhalten mit meinem ConnectionString, mit und ohne Angabe des festen Ports.

An der Konfiguration des MSSQL-Server wird nichts verändert. Am Server auch nicht.
Die Client-PCs bauen aber hin und wieder VPN-Verbindung nach irgendwo hin auf (UseRasCredentials=0 kenne ich).

Auf dem Win-2012 läuft ein virtueller Win-2003 Terminal-Server, auf dem ebenfalls mein Anwendung läuft,... genau die gleichen Probleme, welche aber offenbar sitzungsabhängig sind. Während die eine Sitzung keine Verbindung bekommt, läuft in der anderen alles ohne Probleme.

Ich drehe noch durch :wall:

Ich habe den Eindruck, dass dieses Problem erst seit dem Win-2012-Server besteht, denn andere Installationen, wo der MSSQL-2008 auf einem Win2008-Server läuft gibt es keine derartigen Probleme.
"Denkt" die Firewall auf den Win-2012 evtl. mit??

Hat jemand von euch ähnlich Beobachtungen gemacht? Kann mir irgendwer einen Tipp geben?

Danke und Grüße
gmc

[madtom]

Hallo,

ich weiß nicht, ob es was bringt, aber mein Connection String kommt ohne Hochkommas aus.

Gruß

Thomas

[Dejan Vu]

Gehts schneller, wenn Du die IP-Adresse statt des Servers verwendest? Dann wäre die Namensauflösung das Problem.

Dynamische Ports und Firewall wäre jetzt nicht direkt kompatibel, da würde ich schon einen festen Port nehmen.

[Sir Rufo]

Definiere doch mal

Zitat:

Zitat von gmc616 (Beitrag 1267742)

... per TADO über den selbst gebauten ConnectionString

Code:

Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;User ID="";Initial Catalog="MyBase";Data Source="w2k12data\sql2008";Initial File Name="";Server SPN=""

Ich bin da immer etwas faul und mache einen Doppel-Klick auf die ADOConnection und erzeuge mit dem Dialog den ConnectionString.

Empfehlen würde ich auch die Verbindung über den SQL Native Client.

[Dejan Vu]

Oder: Leere TXT-Datei erstellen, Extension auf 'UDL' ändern, doppelklicken, Verbindung einrichten, speichern, mit Notpad öffnen. Falls man kein Delphi zur Hand hat.

[Bernhard Geyer]

Zitat:

Zitat von Dejan Vu (Beitrag 1267773)

Gehts schneller, wenn Du die IP-Adresse statt des Servers verwendest? Dann wäre die Namensauflösung das Problem.

Könnte ich mir vorstellen. Vor allem wenn VPN im spiel ist wird ja an den Routen "herumgedocktert".

[gmc616]

Zitat:

Zitat von Sir Rufo (Beitrag 1267774)

Ich bin da immer etwas faul und mache einen Doppel-Klick auf die ADOConnection und erzeuge mit dem Dialog den ConnectionString.

Was nützt es mir, wenn ich für jede Installation eine neue Echse kompilieren muss? Oder verstehe ich dich falsch?
Der ConnectionString wird zentral auf einem Netzlaufwerk abgelegt, so das man nicht für jeden Client-PC die Verbindungseinstellungen vornehmen muss.

Zitat:

Zitat von Sir Rufo (Beitrag 1267774)

Empfehlen würde ich auch die Verbindung über den SQL Native Client.

Den Gedanke hatte ich auch. Allzumal der Native Client schneller sein soll als OLEDB. Stimmt das?
Allerdings habe ich gelesen, dass MS die Verbindung per Native Client ab MSSQL-2008R2 nicht mehr zulässt, was aber wiederum deinen verlinken Artikel widerspricht. :?

Auch stellt sich hier das Problem, dass der Native-Client für jeden PC nach installiert werden muss. Meine Support-Admins werden sich bedanken ... :lol:
Wenn es aber das Problem löst ...

@Thomas: An den Hochkommas liegt es nicht. Im Gegenteil, die Endanwender kommen auf die idiotischsten Namen für Ihre MSSQL-Instanzen. :stupid:

@Dejan Vu: Cooler Tipp mit der UDL-Datei! Werde ich sicherlich verwenden können :thumb:

Zitat:

Zitat von Bernhard Geyer (Beitrag 1267782)

.. Vor allem wenn VPN im spiel ist wird ja an den Routen "herumgedocktert".

Die VPN habe ich auch im verdacht. Kann sie aber nicht auf den Client-PCs "verbieten lassen". Die werden benötigt.
Allerdings werden auf dem Server und Terminal-Server keine VPNs aufgebaut. Und das Problem existiert auf dem Terminal-Server trotzdem, weswegen ich den Win-2012-Server ansich im Verdacht habe.
Hab aber von Netzwerken auch nicht so die tiefgehenden Kenntnisse.:freak:

Kann eine VPN-Verbindung vom Client-PC nach irgendwohin, die RDP-Sitzung so manipulieren, das darin (in der RDP-Sitzung) die MSSQL-Verbindung flöten geht??

[Uwe Raabe]

Zitat:

Zitat von gmc616 (Beitrag 1267910)

Kann eine VPN-Verbindung vom Client-PC nach irgendwohin, die RDP-Sitzung so manipulieren, das darin (in der RDP-Sitzung) die MSSQL-Verbindung flöten geht??

Wenn es eine normale VPN-Verbindung unter Windows ist, wird damit das Standardgateway auf die VPN-Verbindung umgeleitet. Das kannst du in den erweiterten TCP/IP-Einstellungen der VPN-Verbindung nachsehen und auch dort abschalten. Das bedeutet aber auch, daß du die Routen in das VPN-Netz von Hand anlegen musst, weil dein lokales Netzwerk die ja nicht kennt.

Dieses Umlegen des Standardgateways hat z.B. zur Folge, daß bei aktivem VPN alle Verbindungen ins Internet über das VPN laufen - was häufig deutlich langsamer ist.

[arnof]

soweit mir bekannt, gibt es generelle Probleme von MSSQL 2008 auf einem 2012 Server.

Teste doch einfach mal einen MSSQL 2012 Express, ob da dass nicht gut geht

[Sir Rufo]

@gmc616

Ich baue mir den Connection-String niemals selber, sondern lasse mir den durch den Dialog erstellen und speicher den dann ab. Darum verstand ich deine Aussage mit dem selbst gebauten nicht.

Hast du den über den Dialog erzeugt oder von irgendwoher kopiert und angepasst?