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

[cltom]

Hallo,

ein Thema, bei dem ich strauchle, aber auch keine gute Lösung finde.

Es soll die Verfügbarkeit eines SQL-Servers geprüft werden, aber ohne User-Interaktion. Ich verwende ZeosLib, hab nun aber auch Unidac verfügbar. Ich hab es mit ZConnection.Ping probiert, das klappt aber nicht, da wirft er bei nicht-Verfügbarkeit einen Fehler. Ich hab es mit Exceptions um das Connect probiert, aber da kommt ebenso die Exception. In jedem Fall ist es auch für den User sichtbar, dass mal "nichts" passiert und das Programm reagiert mal nicht. Ich hab auch versucht, den Timeout zu reduzieren, das klappt auch nicht (warum auch immer: der Timeout-Wert scheint ignoriert zu werden).

Ideal wäre es, wenn ich "still" testen kann, ob der Server verfügbar ist, ohne dass Sekunden vergehen, wo der User nichts machen kann.

Danke für Ideen!

gruß
tom

[KodeZwerg]

Es gibt unter den meisten "Connection" varianten auch eine "Connected" Property, wenn diese "False" ist, sollte der Server offline sein.

[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:

Zitat von KodeZwerg (Beitrag 1514180)

Es gibt unter den meisten "Connection" varianten auch eine "Connected" Property, wenn diese "False" ist, sollte der Server offline sein.

ok, aber zuerst muss ich ja mal versuchen, zu verbinden. Und wenn der Server da nicht zu erreichen ist, wirft es schon eine Exception. Danach kann ich, wie Du beschreibst testen, ob ich verbunden bin. Aber da hab ich den Schritt, den ich suche, bereits hinter mir.

[cltom]

Zitat:

Zitat von dstein (Beitrag 1514189)

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!

[cltom]

Zitat:

Zitat von Medium (Beitrag 1514198)

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

[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. :stupid:

[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';