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