SQL-Server 2017, ADOConnection und LogIn-Timeout

[FrankJ28]

Hallo in die Runde,
wir betreiben seit etlichen Jahren eine Datenbank auf SQL-Server im Netz. Bislang Version 2012, jetzt migriert auf 2017. Seit der Umstellung ist der Zugriff via ADO etwas "zickig", die erste Connection läuft in ein TimeOut (Unable to complete Login process due to delay in Opening Server Connection). Auch nachzustellen via zugehörigem UDL-File, Test Connection. Verrückterweise steht die Verbindung aber, der Datenzugriff klappt. Der 2. Versuch die Verbindung aufzubauen klappt hingegen einwandfrei, ohne TimeOut. Gleiches Verhalten beim Test des UDL-Files, 2. Versuch klappt sofort. Jemand eine Idee, was da schief geht?
Danke und ciao
Frank

[KodeZwerg]

Es gibt Umstände da benötigt die Abfrage über 15 Sekunden, dann erscheint der Time out.
Man könnte entweder den TimeOut über TADODataSet und TADOConnection höher setzen (CommandTimeout) um der DB mehr Zeit zu verschaffen oder vielleicht am "select * from" rumschrauben.

[FrankJ28]

Hallo,
danke für deine Idee. Nö, ein Statement wird da noch nicht abgesetzt, ist tatsächlich nur Connection.open. Wie gesagt, gleiches Problem ist ja auch schon mir dem udl-File zu reproduzieren.
Ciao
Frank
Zu meinem Post: udl-File, nicht udp (was hat mich den da geritten, sorry für die Verwirrung, habe ich noch korrigiert)

[p80286]

Du kannst den Timeout der Adoconnection ja gezielt definieren.
Aber zuerst würde ich den Provider überprüfen.

Gruß
K-H

[Papaschlumpf73]

Benutzt du den Standard OLE DB Provider SQLOLEDB oder den speziellen Provider vom SQL Native Client?

[hoika]

Hallo,
hier
https://www.sqlservercentral.com/For...192-146-1.aspx

ganz unten steht was von DSN-Auflösung, weiter oben von Client 10.0 als Problem.
Ist vielleicht auch der Rechner neu?
Steht die DNS-Adresse oder der Rechner-Name im Connection-String?

[jobo]

Ich würde auch mal auf eine schlechte Namensauflösung tippen.
Zeig mal den Connection string.
Stelle sicher, dass der richtige DNS Name verwendet wird.
Prüfe mit Ping und Tracert die Erreichbarkeit der Hardware/des Rechners.

Ersetze den Rechnernamen im Connectionstring durch die IP (probehalber).

Prüfe ggF. Probleme, die durch IPV4, IPV6 Addressierung (und dafür jeweils schlechtes Routing) entstehen können.

[FrankJ28]

Hallo in die Runde,
vielen Dank für eure Mühe mitzudenken.

Genutzt wird SQLOLEDB in der TADOConnection
Die Timeouteinstellungen beziehen sich offensichtlich nur auf ein abgesetztes Command, das "OPEN" und der hier gemeldeten fehlschlagenden Authentifizierung bleibt davon unberührt. Die Meldung ist wohl auch falsch, da dann der Open ja trotzdem funktionierte, Datenzugriff ist wie gewohnt möglich.
Den Tipp mit dem FLUSHDNS habe ich probiert, leider kein Erfolg.
Danke und ciao
Frank

[FrankJ28]

Hallo Jobo,
der Rechner ist sonst über den Namen sauber und schnell erreichbar. Lediglich der SQL-Server-Verbindung hagelt etwas dazwischen, aber auch erst seit Migration auf 2017.
Der ConnectionString aus dem UDL:

Code:

[oledb]
; Everything after this line is an OLE DB initstring
Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=FaktFam;Data Source=SERVER2012\SQLEXPRESS

Danke und ciao
Frank

[FrankJ28]

Hallo in die Runde,
das Problem ist (warum auch immer) behoben. Folgendes habe ich getan:
1. Alle SQL-Server Dienste gestoppt, DB-Verzeichnis umbenannt
2. Deinstallation SQL-Server, auch Reste älterer Versionen
3. Neuinstallation SQL-Server 2017
4. Connection-Test, noch immer TimeOut, gleiches Verhalten wie die Migration
jetzt festhalten:
5. vor dem Server/Instanzenname ein tcp: eingefügt und huups klappt wie verrückt.
6. Erneuter Versuch ohne tcp:, klappt noch immer, jetzt auch auf allen anderen Rechnern im Netz wieder.

Informationsquelle:
https://social.technet.microsoft.com...se-engine.aspx

Danke für euer "Gehirnschmalz"
Ciao
Frank