MSSQL-Verbindung - mal gehts, mal nicht

[Sir Rufo]

Definiere doch mal

Zitat von gmc616:

... 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.

[gmc616]

Zitat von Sir Rufo:

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 von Sir Rufo:

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 ...
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.

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

Zitat von Bernhard Geyer:

.. 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.

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 von gmc616:

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?

[gmc616]

Zitat von Uwe Raabe:

Zitat von gmc616:

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.

Ja okay, das erklärt das Verhalten der Client-PCs. Aber die VPN am Client-PC ändert doch nicht Routen vom/im Terminal-Server, oder? Wie gesagt, dort tritt das Problem ebenfalls auf und dort werden definitiv keine VPNs aufgebaut.

Ich werde mal das MSSQL-Servicepack für 2008R2 prüfen bzw. installieren lassen. Mal sehen ob das hilft.

@Sir Rufo: Irgendwoher kopiert und angepasst. Werde mal das Ganze mit dem Tipp von Dejan Vu vergleichen.

Aber wie gesagt, das Problem besteht mEn. erst seit dem Umstieg auf Win-2012 Server. Glaube nicht, dass der ConnectionString daran schuld ist. Auf den alten 2008-Servern bzw. 2003-Servern gibt es derartige Probleme nicht. Allerdings ist mein Test-Server ebenfalls ein 2012, hier kann ich das Problem nicht nachvollziehen.