ADO Verlorene Verbindung wieder finden

[nahpets]

Wenn eine ADO-Verbindung kaputt ist, ist sie kaputt.

Die Schritte 2 und 5 wirst zu auf jeden Fall benötigen.

Eine Reanimation einer gestörten Verbindung, mit Fortsetzung im Zustand vor der Störung, ist nicht möglich.

DataSets benötigen eine dauerhaft, ungestörte Verbindung.
Nach einem Verbindungsverlust ist eine Reanimation und/oder ungestörte Fortführung im aktuellen Zustand nicht möglich.

Bei einem Verbindungsverlust bleibt Dir nichts anderes übrig, als Dir für jeden Dataset die aktuelle Position des Datensatzzeigers... zu merken und nach dem Schließen aller DataSets beim Öffnen an diese Positionen zurückzukehren.

Alternative:

Alle Daten im Client vorhalten und nur Änderungen bei Bedarf an die Datenbank weitergeben bzw. von dort holen.

[Dejan Vu]

Hmmm. Du arbeitest also mit Datasets. Nun gut. Nimm halt ClientDataSets (wurde schon erwähnt). Bei einem Refresh geht das über eine zentrale Routine, die dann eben das Reconnect-Gedöns implementiert.

Jetzt kann man sich natürlich hinstellen und sagen: "Ich will aber, das das ohne Umschreiben trotzdem funktioniert". Klar. Kann man. Bringt nur nix. :lol:

[arnof]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1325535)

Wenn jetzt die Verbindung erst nach löschen und wieder setzen des Connectionstrings funktioniert würde das m.E. darauf hin deuten das in diesem Fehlerfall die dbGo-Implmentierung (Der VCL-Teil muss nach invervention so genannt werden) nicht mehr synchron mit den ADO/OLEDB-Status. Oder alternativ (was ich nicht glaube) ist hier noch ein ConnectionPool aktiv der dafür sorgt das eigentlich kaputte Connnections weiter verwendet werden.

Genau diesen ConnectionPool will ich irgendwie zurücksetzen, da war meine Frage, ob das schon mal jemand hin bekommen hat.

PS: ClientDataSet will ich nicht da es hier nicht um eine Neuentwicklung geht, sondern um ein bestehendes Produkt was super läuft. Ich will ja nur die Netzwerkprobleme beim Kunden umschiffen, auf die ich keinen Einfluss habe. Wenn das Prg 2-3 sec hängt und dann weiter läuft ist alles save. Nur wenn man es erst per Taskmanager Killen muss, weil ein DataSet nach dem andern wegfliegt ist das nicht gut.

[Dejan Vu]

Ah, verstanden. Gibt's keinen Event, in den man sich einklinken kann (zur Not mit TTimer), um dann irgendwie von Hinten durch die Brust ins Auge ein Reconnect durchzuführen?

[arnof]

Zitat:

Zitat von Dejan Vu (Beitrag 1325558)

Ah, verstanden. Gibt's keinen Event, in den man sich einklinken kann (zur Not mit TTimer), um dann irgendwie von Hinten durch die Brust ins Auge ein Reconnect durchzuführen?

Ich weiss nicht was das soll, ich bitte doch darum nicht nur dumm rumzulabern, wenn kann davon keine Ahnung hat und einfach keine Lösung kennt dann sollte man sich doch einfach zurückhalten.

[arnof]

So für die die es interessiert und irgendwann diesen Beitrag bei Google finden:

Lösung ist ganz einfach und auch via VPN Verbindung getestet:

2. Connection drauf, diese muss Connected=False sein

Wenn es zum Netzproblem kommt und das Netz wieder da ist und es kommt trotzdem "Fehler beim Verbinden", dann der 2. Connection Connected auf False und ConnectString der ersten Übergeben Connected auf True setzen, wenn die Verbindung steht, so kann bei einem geöffneten und sogar editierten ADODataset die Connection geändert werden. Diese also auf die 2'te setzen, danach gehen auch alle Updates und inserts automatisch durch .....

Danke fürs helfen :thumb:

[Dejan Vu]

Zitat:

Zitat von arnof (Beitrag 1325564)

...wenn kann davon keine Ahnung hat und einfach keine Lösung kennt dann sollte man sich doch einfach zurückhalten.

Ich finde deine Antwort auf einen Tipp sehr entlarvend.

Übrigens: Dein Schlips schleift auf dem Boden.

[TRomano]

Letztlich muss er erst einmal schauen, ob er ein Hardware-Problem hat. Wenn das, so gut es geht, ausgeschlossen ist kann er sich an dann eventuell noch vorhandene Software-Probleme machen.
Gibt es bei der ADO-Connection (habe ich schon ewig nicht mehr benutzt) kein Event wie "OnConnectionLost" (UniDAC), dass man dort auf das Verlieren einer Connection reagieren kann ? Wenn nicht müsste man wirklich in einem bestimmten Intervall die Verbindung abfragen und entsprechend reagieren.

[arnof]

Zitat:

Zitat von TRomano (Beitrag 1325577)

Letztlich muss er erst einmal schauen, ob er ein Hardware-Problem hat. Wenn das, so gut es geht, ausgeschlossen ist kann er sich an dann eventuell noch vorhandene Software-Probleme machen.
Gibt es bei der ADO-Connection (habe ich schon ewig nicht mehr benutzt) kein Event wie "OnConnectionLost" (UniDAC), dass man dort auf das Verlieren einer Connection reagieren kann ? Wenn nicht müsste man wirklich in einem bestimmten Intervall die Verbindung abfragen und entsprechend reagieren.

-Energiesparmodus der Netzwerkkarte in der Mittagspause und schon ist die Verbindung weg, nur mal als Beispiel.
-Laptop klappt man zu und will genau dort weitermachen, wo man war
-3'tes Beispiel Technikerdepp zieht das falsche Netzkabel im laufenden Betrieb und steckt es schnell wieder rein: 20 Kunden stehen an der Kasse: wer ist schuld : die Software
-4'tens auf der CeBit macht man was mit W-LAN nicht weit von unserem Stand ist Samsung, die pusten das beste W_Lan in die Störung ....


Es ging hier nicht um Glaubens fragen was alles besser ist oder wer hier besser und schöner ist und das jeder alles besser weis, sondern um eine zielführende Lösung, aber so ist das in Foren!

[Sir Rufo]

Nun ja, das Grundproblem ist ja, dass dieses ADO Geraffel dafür einfach nicht ausgelegt ist. Andere Komponenten machen es da eben besser und man kann in einem Event diese Verbindung wieder neu aufbauen.

Um diesem ADO nun so etwas beizubringen muss man dieses - abenteuerlich anmutende - Tauschen der Verbindung vornehmen.

Die andere Alternative wären die ClientDataSets gewesen (und erheblich mehr Aufwand beim Umsetzen).

Bei einer "muss jetzt schnell fertig werden" Situation würde ich auch die erste Variante wählen ;)