Still prüfen, ob SQL Server verfügbar ist

[dstein]

Ich benuze UNIDac anbei ein kleines TestPrg.
Nur einen SQL Server anpingen ob der da ist ist doch zu wenig, du willst doch wissen ob eine Datenbank / Instance erreichbar ist.
In meinem kleinen Sample gibt die Connection einen Wert zurück.
Evtl. eine Gedankenanregung.
Gruß Dirk

[Medium]

Ich arbeite mit UniDAC und mache das bisher auch immer ganz simpel in einem try..except.

Ganz vereinfacht:

Delphi-Quellcode:

try
  SQLCon.Connect;
except
  GlobalLog.Add('Verbindungsversuch zu '+SQLCon.Servername+' fehlgeschlagen');
end;

Man sollte allerdings um es ganz korrekt zu haben, die Exception-Klasse auch auswerten.

Das am liebsten in einem Thread, sodass mir das UI beim Warten auf den Timeout nicht einfriert. Wirft keine sichtbaren Exceptions. (Man braucht aber natürlich einen SQL-User dafür, der sich zumindest verbinden darf. Ansonsten bräuchte es ja ein Login-Prompt.)

[cltom]

Zitat von Medium:

Ich arbeite mit UniDAC und mache das bisher auch immer ganz simpel in einem try..except.

Ganz vereinfacht:

Delphi-Quellcode:

try
  SQLCon.Connect;
except
  GlobalLog.Add('Verbindungsversuch zu '+SQLCon.Servername+' fehlgeschlagen');
end;

Man sollte allerdings um es ganz korrekt zu haben, die Exception-Klasse auch auswerten.

Das am liebsten in einem Thread, sodass mir das UI beim Warten auf den Timeout nicht einfriert. Wirft keine sichtbaren Exceptions. (Man braucht aber natürlich einen SQL-User dafür, der sich zumindest verbinden darf. Ansonsten bräuchte es ja ein Login-Prompt.)

Danke Dir! Einen Thread aufzumachen ist wohl eine Variante, um das Hourglass zu vermeiden. Elegant ist ja, wenn der User nicht offensichtlich mitkriegt, dass man erst mal nachschaut, ob der Server verfügbar ist.

Ich dachte an ein einfaches Ping, das mir true/false zurückgibt ...

[dstein]

ich verbinde mich mit einer MS SQL Serverdatenbank, wenn der Server nicht vorhanden ist dauert es ca. 12 Sekunden bis UniConnectionMainError einen Error zurück gibt.
Ich habe bei Devart (Pavel Podlepinskiy) mal ein Ticket aufgemacht ob es einen Weg gibt um die Antwortzeit zu verkürzen.
Denn ein Connect erfolgt in einer Sekunde, aber wenn Connect misslingt ca. 12 Sekunden.
Obwohl: UniConnectionMain.SpecificOptions.Values['ConnectionTimeout'] := '1';

[himitsu]

Beim pgDAC und DataSnap hab ich auch schon mehrmals mitbekommen, dass einige Timeout-Settings gern ignoriert werden.

Aber dafür gibt es oft eine gute Lösung.
In der neusten Version hat Emba jene Timeoutproperties bei sich gelöscht.

[dstein]

Nachtrag!
Wenn der Provider nicht auf "prAuto" sondern expliziet auf prDirect, prNativeClient oder prMSOLEDB steht.
Dann erhalte ich eine Rückmeldung, das der Server nicht verfügbar ist innerhalb von 2-3 Sekunden.

UniConnectionMain.SpecificOptions.Values['Provider']:='prNativeClient';
{ prDirect, prAuto,prSQL,prNativeClient,prCompact,prMSOLEDB}
UniConnectionMain.SpecificOptions.Values['ConnectionTimeout']:='1';

[cltom]

Zitat von dstein:

Ich benuze UNIDac anbei ein kleines TestPrg.
Nur einen SQL Server anpingen ob der da ist ist doch zu wenig, du willst doch wissen ob eine Datenbank / Instance erreichbar ist.
In meinem kleinen Sample gibt die Connection einen Wert zurück.
Evtl. eine Gedankenanregung.
Gruß Dirk

Danke für das Beispiel. Es gibt auch hier ein sichtbares einfrieren/warten auf die Verbindung, aber ja, die Exception wird so schön im Hintergrund gehalten, ohne dass eine Meldung kommt. Mit dem Vorschlag weiter unten, einen Thread aufzumachen wird das wohl die Lösung sein. Danke!