Moin...

Ich hätte da gern mal ein Problem...

Ich beziehe mich mal nur auf IBDAC. Das ganze kann mit anderen Komponenten sich ganz anders verhalten.

IST:
* DB Connection im Mainthread
Wenn während einer bestehenden Connection die Verbindung abbricht (Putze über Netzwerkkabel gestolpert) bekommt die Anwendung das, in der Regel, nicht mit. Beim nächten Zugriff auf die DB hängt mir immer die Anwendung und schmeißt noch nicht mal eine Exception. Dann würde nämlich ein MessageDialog aufgehen und die Anwendung, nach OK, sicherheitshalber beendet. Oder der Mainthread hängt schon vorher fest...

SOLL:
Auswertung des Verbindungsabbruches und Neuconnection.

Wie händelt ihr so etwas?
In einer anderen Anwendung habe ich die DB Verbindungen in Threads. Dort beende ich, im Fehlerfalle, den jeweiligen Thread von außen und starte ihn nach einer Zeit X neu. Damit wird die DB Verbindung "abgewürgt" und neu aufgebaut. Das funktioniert gut. Wie aber wenn es im Mainthread abläuft?

PS:
IBDAC hat eine Property (LocalFailOver in Verbindung mit OnConnectionLost.) die bei Verbindungsabbrüchen das entsprechend händeln soll. Ich habe es nicht stabil hinbekommen.
Die Tipps wie hier z.B. http://www.delphipraxis.net/163086-f...abbrueche.html erwähnt habe ich auch durch.


Danke für Info´s.

Also wir haben eine prima Putzfrau, ich kenne solche Probleme nicht.


Ernst: Wenn es die Putzfrau war, macht das von Dir angestrebte Verfahren Sinn? Steckt die das Kabel gleich immer wieder rein?
Worauf ich hinaus will. Falls es um eine instabile (WAN) Verbindung geht, muss man da vielleicht anders ran, als der Umgang mit Stecker raus, Server down, ... denn hier nützt ein auto reconnect kurzfristig wahrscheinlich gar nichts.

Das mit der Putzfrau ist weit hergeholt...

Im speziellen habe ich auf meiner Maschine den Firebird laufen und verbinde mich nicht über localhost sondern über den Servernamen. Gleichzeitig besteht ein VPN (nicht aus meiner Anwendung heraus) nach extern. Bei der allnächtlichen Zwangstrennung des DSL wird nicht nur das VPN getrennt und wieder neu aufgebaut, sondern auch die Datenbankverbindung der laufenden Anwendung zum Firebird Server wird, wahrscheinlich kurzzeitig, gekappt. Warum das so ist kann ich nicht sagen. Dieses verursacht diesen Effekt. Ich würde gern solche Eventualitäten sauber behandeln. Wenn ich die Anwendung über Nacht laufen lasse kann ich sie beim nächsten Benutzen einfach nur abschießen. Das gefällt mir mal gar nicht.

Eines der zentralen Punkte ist es dabei, ob du mit Datatsource/Dataset arbeitest (so wie das ca. 95% aller Delphianer machen) oder die gerade gebrauchten Daten in eigenen Strukturen/Objekten/Listen im Client speicherst (so wie unter anderem wir das mittlerweile nur noch machen). Das zweite Verfahren ist bei uns sogar immun gegen das Umschalten auf einen zweiten replizierten Server, falls der erste nicht mehr erreichbar ist. Bei Datasource/Dataset musst du ziemlich viel wieder herstellen, damit der Anwender wieder annähernd das gleiche sieht wie vorher. Die DS/DS Komponenten verlieren beim Verbindungsabbruch nämlich so ziemlich alles, was die brauchen, um wieder sinnvoll als zu arbeiten (TField Objekte, Transaction bzw. Query Handles, Bookmarks bzw Cursorposition, etc).

Einige Komponenten für Datasource/Dataset Operationen können das zwar relativ gut vereinfachen, aber perfekt hat das aus meiner Sicht keine einzige gelöst, daher auch der komplette Umstieg weg davon bei uns. Wenn ich was von der Datenbank will, sag ich der das, wenn die dann nicht antwortet, reagier ist eben so wie ich will (u.a. umschalten auf anderen Server, lokale Storage oder was auch immer). Aber nur weil irgendjemand bei mir im Front End durch eine Datenmenge scrollt, werden noch lange keine weiteren Datensätze gefetcht. Und ganz nebenbei geschieht auch nahezu alles in extrem kurzlebigen Transaktionen.

Das löst zwar ggf. deine Probleme auf Basis Datasource/Dataset nicht, sofern du das benutzt, aber es geht ja auch in deiner Frage um Prinzip Fragen.

Also die Putzfrau taugt als plakatives Beispiel eigentlich. Bei mir waren das jedoch eher überintelligente Switches (Cisco!) oder ein instabiles WAN (wie bereits erwähnt). Richtfunk (in ruralen Gebieten in Madagaskar) sind auch Kandidaten für ein derartiges Szenario.

Holger hat schon Recht: In so einem Fall bringen die KlickibuntiDatasets rein gar nichts. Aber die bringen auch so nichts, weil ein instabiles WAN i.a. auch mit reduzierter Bandbreite einhergeht. Ergo kann man sich die Kundenliste nicht präventiv einladen, sondern muss mit Queries, Pagination und Objektpersistenz etc. arbeiten.

Danke an alle...

Von Datasets habe ich mich schon vor längerer Zeit getrennt. In meinen Anwendungen liegen die Daten als Objekte in generischen Listen. Dazu gibt es eine Datenbankschicht als Interface die ausschließlich reines SQL absetzt...
Der Fehler tritt dann immer auf wenn das SQL abgesetzt wird. Es geht quasi nur um die Connection die wieder die Verbindung herstellen muß. Selbst das letzte Statement müßte nicht erneut ausgeführt werden.

Ich werde mal noch ein wenig mit dem OnConnectionLost Event vom IBConnection rumspielen. Das soll ja dann genau greifen. Bei den letzten Versuchen (vor 1 Jahr oder so ) war das nicht von Erfolg gekrönt.

Nur mal so als Idee.
In regelmäßigen Abständen ein Ping an den DB-Server senden ob aktuelle Verbindung noch aktiv ist?

muss gar kein ping sein, wir holen uns einfach gerne mal den current_timestamp vom firebird server, wenn der kommt ist alles wunderbar.

Das Blöde an der ganzen Geschichte: Es ist aber nicht immer steuerbar. Wir hatten schon Probleme beim Kunden, wo der eigetragene DNS Server
extrem lahm geantwortet hat. Aus dem Grunde sind wir da auf feste IP Adressen umgestiegen. Löste aber auch nicht alle Probleme, denn
bei dem Kunden gab es leider auch 2 Standorte auf 2 Seiten einer Straße und kein direktes Netzwerkkabel. Aus Vereinfachungsgründen
hatte man dann eben eine WLAN Bridge dazwischen gehängt, die auch recht gut funktionierte über ca. 50 m.

Die Firebird Anwendungen auf der anderen Seite waren aber leider schon ein wenig träger, das konnte man aber mit den Ping Zeiten
auch nachvollziehen, denn da war nichts mehr mit 0 ms wie im eigenen Netz, sondern je nach Lust und Laune 1-5ms ....

Komplett zusammengebrochen ist das Netz dann mal, als es extrem geschneit hat. Auch bei starken Gewitterregen leidet die Empfangsqualität
scheinbar erheblich. Das äußerte sich leider auch nicht in sofortigen Verbindungsabbrüchen, sondern manchmal passierte sekundenlang
nichts und dann ging es wieder los.

Den gleichen Effekt kenn ich von einem anderen Kunden, der eine Fat Client Windows Anwendung mit Firebird Connection auf seinen Gabelstaplern
betreibt. In einem Bereich in der Halle ist trotz direkter Nähe eine Accesspoints kein zuverlässiger WLAN Empfang. Sobald das Staplerterminal
da eine Verbindung versucht hat, steht aus der Sicht des Terminals die WLAN Verbindung und kommt auch nicht mehr ins Netz, wenn der woanders
hin fährt.

Die haben schon alles mögliche ausgetauscht und deren Systemhaus stand schon mehrfach am Rande des Wahnsinns, hat aber alles nichts
gebracht. Wenn das Ding hängt, musste es neu gestartet werden ... Die Firebird Anwendung da drauf bekam vom WLAN Protokoll weder
einen Fehler noch sonst irgendwas, bekam also keine Exception, auf die man hätte reagieren können. Ob das nun am WLAN, am AP, am Terminal
oder an sonstwas liegt, ist nicht klar. Lösung beim Kunden war einfach: Da stehen jetzt die Regale so, das da kein Stapler mehr hinfahren
kann. und der betroffenen Bereich wird für andere Sachen benutzt.

Zitat von haentschman:

Ich werde mal noch ein wenig mit dem OnConnectionLost Event vom IBConnection rumspielen. Das soll ja dann genau greifen. Bei den letzten Versuchen (vor 1 Jahr oder so ) war das nicht von Erfolg gekrönt.

ich befürchte mal das du bei Netzwerkkabel abziehen wunderbar mit Connectionlost arbeiten kannst, wenn der Effekt aber ähnlich dem gerade geschilderten ist, dann leider nicht, weil du noch gar kein connectionlost hast und je nach Netzwerkinfrakstruktur den auch gar nicht bekommen wirst

Zitat:

weil du noch gar kein connectionlost hast

...Das vermute ich auch. Ich werde mich nochmal intensiv damit beschäftigen und werde berichten. Mir würde es ja reichen das die Anwendung Application.Terminate veranstaltet. Ich möchte nur nicht das der User den Taskmanager bemühen muß. Denn das ist immer peinlich...