ADO Verlorene Verbindung wieder finden

[arnof]

Ich habe folgende Problemstellung:

AdoConnection -> AdoDataset alles besten.

Nun bricht die Netzwerkverbindung ab (z.B. W-Lan)! Dataset bleiben offen, wenn ein Dataset z.B. eine Änderung an den Server senden will bekommt man "Fehler beim Verbinden" beim ADO Dataset, ok ist ja richtig (das DataSet wird Active False "ohne mein zutun")


Nun steht die Netzwerkverbindung wieder AdoConnection ist noch Connected und alle anderen Verbunden DataSet sind auch noch Active (bis auf die Eine)!

Nun will ich das DataSet wieder öffnen, dies wird weiterhin verweigert mit "Fehler beim Verbinden".

Lösung z.Z. AdoConnection auf Connected=False setzen, ConnectionsString leeren, neu Befüllen und neu Verbinden, dann geht wieder alles.

Das ist leider schlecht da viele DataSets offen sind und ich eigentlich dem AdoConnection sagen will, das er sich erneut verbinden soll, ohne die anderen DataSet zu schließen.

Kennt jemand eine Lösung ?

[Sir Rufo]

Die Connection kennt alle DataSets, die über diese verbunden sind.

http://docwiki.embarcadero.com/Libra...ction.DataSets

Da könntest du jetzt vor dem Schliessen der Verbindung alle aktiven DataSets merken, dann die Verbindung schliessen, wieder aufbauen und dann alle gemerkten DataSets wieder auf aktiv setzen.

Generell würde ich aber die normalen ADO DataSets gegen ClientDataSets tauschen.

[Bernhard Geyer]

Zitat:

Zitat von arnof (Beitrag 1325452)

Das ist leider schlecht da viele DataSets offen sind und ich eigentlich dem AdoConnection sagen will, das er sich erneut verbinden soll, ohne die anderen DataSet zu schließen

Das geht aber nicht anders. Die Verbindung die sie aufgebaut haben sind zwangsweise schon "Tot" auch wenn Active noch auf True steht.

[Perlsau]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1325457)

Das geht aber nicht anders. Die Verbindung die sie aufgebaut haben sind zwangsweise schon "Tot" auch wenn Active noch auf True steht.

Genau :thumb: Die Fehlermeldung wird erst ausgelöst, wenn man so ein "totes" Dataset in Anspruch nimmt.

Zitat:

Zitat von arnof (Beitrag 1325452)

Lösung z.Z. AdoConnection auf Connected=False setzen, ConnectionsString leeren, neu Befüllen und neu Verbinden, dann geht wieder alles.

Wieso mußt du den Connectionstring neu zuweisen? Hat sich denn in der Zwischenzeit an den Verbindungsdaten etwas geändert?

Zitat:

Zitat von arnof (Beitrag 1325452)

Das ist leider schlecht da viele DataSets offen sind und ich eigentlich dem AdoConnection sagen will, das er sich erneut verbinden soll, ohne die anderen DataSet zu schließen

Was ist daran schlecht? Machst du das beim Programmstart nicht ebenfalls? Die Frage bezieht sich darauf, daß ich immer wieder beobachte, wie Programmierer ihrer Anwendungen mit aktiver Datenbankverbindung kompilieren oder die Datenbankverbindung aktiv ist, wenn sie Delphi schließen. Das ist keine gute Idee, denn erstens ist nicht immer garantiert, daß der Datenbankserver und/oder die jeweilige Datenbank erreichbar ist, was zu Fehlermeldungen bereits beim Start der IDE führen kann. Und zweitens ist das kein guter Programmierstil, finde ich, weil das zu unerwartetem Verhalten führen kann.

In meinen Datenbank-Anwendungen gibt es immer eine

Delphi-Quellcode:

Function TDatMod.Verbinden_Datenbank : Boolean

; und eine

Delphi-Quellcode:

Function TDatMod.Verbinden_Queries : Boolean;

. Liefert die erste False zurück, lese ich das Property Fehlertext aus meinem Datenmodul aus und beende das Programm mit dieser Fehlermeldung. Dasselbe dann für die zweite Funktion. Zudem kann ich so erstens steuern, in welcher Reihenfolge meine Datasets oder Queries aktiviert werden sollen, und zweitens, welche Queries gleich geöffnet werden und welche erst bei Bedarf. In bestimmten Fällen benötige ich auch mal eine

Delphi-Quellcode:

Procedure TDatMod.Schliessen_Queries;

oder

Delphi-Quellcode:

Procedure TDatMod.Disable_DataSources;

All das habe ich in einem Default-Datenmodul bereits vorbereitet, und weil ich die DB-Connection immer ConMain nenne und ich immer eine Benutzer-Tabelle für benutzerdefinierte Einstellungen habe, existiert auch immer schon ein Qset_Benutzer, so daß ich beide Funktionen schon mal drin habe.

[arnof]

Zitat:

Zitat von Perlsau (Beitrag 1325459)

Zitat:

Zitat von arnof (Beitrag 1325452)

Lösung z.Z. AdoConnection auf Connected=False setzen, ConnectionsString leeren, neu Befüllen und neu Verbinden, dann geht wieder alles.

Wieso mußt du den Connectionstring neu zuweisen? Hat sich denn in der Zwischenzeit an den Verbindungsdaten etwas geändert?

Das muss man machen, sonst baut er die Verbindung komplett nicht neu auf

Zitat:

Zitat von Perlsau (Beitrag 1325459)

Zitat:

Zitat von arnof (Beitrag 1325452)

Das ist leider schlecht da viele DataSets offen sind und ich eigentlich dem AdoConnection sagen will, das er sich erneut verbinden soll, ohne die anderen DataSet zu schließen

Was ist daran schlecht? Machst du das beim Programmstart nicht ebenfalls? Die Frage bezieht sich darauf, daß ich immer wieder beobachte, wie Programmierer ihrer Anwendungen mit aktiver Datenbankverbindung kompilieren oder die Datenbankverbindung aktiv ist, wenn sie Delphi schließen. Das ist keine gute Idee, denn erstens ist nicht immer garantiert, daß der Datenbankserver und/oder die jeweilige Datenbank erreichbar ist, was zu Fehlermeldungen bereits beim Start der IDE führen kann. Und zweitens ist das kein guter Programmierstil, finde ich, weil das zu unerwartetem Verhalten führen kann.

Der Kunde bekommt ja mit das das Verhalten des Programms ein Problem hat. Da alle Systeme mit SSD ausgerüstet sind währe die Anwendung in 10 sec wieder einsatzbereit, das wird aber vom Kunden nicht toleriert, diese muss ohne Bug 100% am Tag laufen!

Wir reden hier nicht von emba Qualität ......


Nun scheint sich ein Hardwareproblem herauszustellen, heute wieder ein Crash nach 5 Stunden Dauereinsatz, hier haben sich meine SQL Anweisungen "von alleine" verändert, die in den Komponenten hinterlegt sind (mitten im SQL Statement sind einzelne Buchstaben verändert). Ich gehe nun von einem Hardwareproblem aus und tausche diese aus.

Trotzdem währe ich an einer Lösung zum Verbindungsproblem interessiert, jeder der z.B. per WLan sonst Mobil arbeitet ist davon betroffen .......

[Bernhard Geyer]

Zitat:

Zitat von arnof (Beitrag 1325507)

Der Kunde bekommt ja mit das das Verhalten des Programms ein Problem hat. Da alle Systeme mit SSD ausgerüstet sind währe die Anwendung in 10 sec wieder einsatzbereit, das wird aber vom Kunden nicht toleriert, diese muss ohne Bug 100% am Tag laufen!

Wenn du deine Anwendung so implementiert hast das alle möglichen Datasets immer offen sein müssen, so sehe ich in diesem Ansatz den Hauptfehler.
Welchen Grund gibt es alle Datasets immer offen zu haben? Wir haben auch mit DBs zu tun und unsere App ist nach einem Reconnect (wenn der Anwender nicht gerade sein System so aufgesetzt hat das er auf oberster Einstiegsebene Tausende Einträge hat) nach 1-2 Sekunden wieder einsatzbereit.

Zitat:

Zitat von arnof (Beitrag 1325507)

Wir reden hier nicht von emba Qualität ......

Ob deine SW besser ist ...

Zitat:

Zitat von arnof (Beitrag 1325507)

Trotzdem währe ich an einer Lösung zum Verbindungsproblem interessiert, jeder der z.B. per WLan sonst Mobil arbeitet ist davon betroffen .......

Wenn du davon ausgehen must das die Netzwerkverbindung öfter Abbricht ist wohl der Fat-Client-Ansatz falsch gewählt.
Evtl. wäre eine Browserlösung oder RemoteDesktop/Citrix-Lösung besser.
Oder eine Überarbeitung des DB-Schnittstelle das diese Daten selbst in Klassen hält und nur noch bei bedarf (Update/Speichern/...) nur kurzzeitig Verbindung mit der DB aufnimmt.

[arnof]

Ich möchte keine Diskussion wer wie alles viel schöner programmiert, das macht keinen Sinn .....

Ihr habe das Problem nicht verstanden:

DataSet gehen auf und zu ....

Wenn nun einmal in x Stunden zu einem Problem kommt (warum auch immer) dann verweigert ADO eine Abfrage obwohl diese wieder möglich ist ohne die Connection zu schließen und wieder zu öffnen.

Hier fragt ich nach einer Idee um der ADO zusagen : "versuche es doch einfach nochmals und ignoriere dein gespeichertes Ergebnis"!

[Perlsau]

Zitat:

Zitat von arnof (Beitrag 1325507)

Zitat:

Zitat von Perlsau (Beitrag 1325459)

Wieso mußt du den Connectionstring neu zuweisen? Hat sich denn in der Zwischenzeit an den Verbindungsdaten etwas geändert?

Das muss man machen, sonst baut er die Verbindung komplett nicht neu auf

Was meinst du damit, daß die Verbindung nicht komplett neu aufgebaut würde? Eine halb aufgebaute Verbindung gibt es nicht: Entweder du hast Verbindung zur Datenbank oder eben nicht.

Das mit dem ConnectionString kann ich hier nicht nachvollziehen. Kannst du einmal überprüfen, wie der ConnectionString aussieht, bevor du ihn neu zuweist? Ich kann mir nämlich nicht wirklich vorstellen, daß der ConnectionString plötzlich zerschossen sein soll. Ein Property-Wert ändert sich nicht einfach von alleine. Ich kann hier jede AdoDB-Connection schließen und öffnen, ohne den ConnectionString neu zuzuweisen, ob jetzt mit MS-Access oder MSSQL. Falls der ConnectionString dennoch zerstört sein sollte, wie du unter von deinen SQL-Anweisungen schreibst, dann hast du vermutlich defekte Ram-Module.

Zitat:

Zitat von arnof (Beitrag 1325452)

Der Kunde bekommt ja mit das das Verhalten des Programms ein Problem hat. Da alle Systeme mit SSD ausgerüstet sind währe die Anwendung in 10 sec wieder einsatzbereit, das wird aber vom Kunden nicht toleriert, diese muss ohne Bug 100% am Tag laufen!

Wenn es Verbindungsabbrüche gibt, die dein Programm nicht zu verantworten hat, dann kannst du daran auch nichts ändern, egal was du da zusammenprogrammierst. Es ging aber darum, daß du die Connection neu aufbauen willst, ohne die Datasets zu schließen. Die sind aber schon geschlossen, wenn die Verbindung abgebrochen ist, denn schließlich hängen die Datasets an der Connection-Komponente. Daß das Property Active der Datasets dennoch auf True steht, hat nichts zu bedeuten. Du mußst also alle Dataset.Active auf False stellen, danach AdoConnection.Connected wieder auf True und erst danach Dataset.Active auf True setzen.

Zitat:

Zitat von arnof (Beitrag 1325507)

Nun scheint sich ein Hardwareproblem herauszustellen, heute wieder ein Crash nach 5 Stunden Dauereinsatz, hier haben sich meine SQL Anweisungen "von alleine" verändert, die in den Komponenten hinterlegt sind (mitten im SQL Statement sind einzelne Buchstaben verändert). Ich gehe nun von einem Hardwareproblem aus und tausche diese aus.

Ein Hardware-Problem kann durchaus dafür sorgen, daß Daten von einer Festplatte fehlerhaft gelesen werden. Allerdings befinden sich die SQL-Anweisungen, von denen du hier schreibst, bereits im Arbeitsspeicher, können also nur aufgrund fehlerhafter Speichermodule falsch gelesen werden.

Zitat:

Zitat von arnof (Beitrag 1325507)

Trotzdem währe ich an einer Lösung zum Verbindungsproblem interessiert, jeder der z.B. per WLan sonst Mobil arbeitet ist davon betroffen .......

Ich denke, hierzu wurde bereits alles gesagt, oder? Wenn du anderer Ansicht bist, wären konkrete Hinweise durchaus hilfreich: Was genau meinst du mit "eine Lösung zum Verbindungsproblem"?

Zitat:

Zitat von arnof (Beitrag 1325511)

Ihr habe das Problem nicht verstanden: DataSet gehen auf und zu ....
Wenn nun einmal in x Stunden zu einem Problem kommt (warum auch immer) dann verweigert ADO eine Abfrage obwohl diese wieder möglich ist ohne die Connection zu schließen und wieder zu öffnen. Hier fragt ich nach einer Idee um der ADO zusagen : "versuche es doch einfach nochmals und ignoriere dein gespeichertes Ergebnis"!

Du behauptest jetzt also, wir alle, die wir dir zu helfen versuchen, hätten das Problem nicht verstanden. Okay, mag ja sein, sowas kann schon mal vorkommen. Aber läge es dann nicht an dir, das Problem so zu schildern, daß auch wir Trottel das verstehen können?

Weiterhin behauptest du, ADO verweigere eine Abfrage, obwohl diese wieder möglich ist, ohne die Connection zu schließen und wieder zu öffnen. Verstehe ich das richtig, daß du damit die Ansicht vertrittst, daß nach einem Abbruch der Verbindung via WLan die Ado-Connection weiterhin aktiv wäre? Sei dir versichert: Genau so ist es nicht. Auch wenn die entsprechenden Properties deiner Komponenten weiterhin den Status True anzeigen (connected, active), ist die Verbindung inaktiv, wenn die WLan-Verbindung abreißt. Datenbanken vergeben Transaktions-Handles, z.B. beim Herstellen einer Verbindung oder beim Ausführen eines Select-Befehls. Diese Handles sind nach einem Abriß der WLan-Verbindung nicht mehr gültig, weshalb du nicht nur die Connection, sondern auch die Datasets erst schließen mußt, bevor du sie wieder öffnen kannst.

So, jetzt klinke ich mich hier aus, bevor ich noch einen irreparablen Hirnschaden erleide :lol:

[arnof]

@Perlsau: nehme nicht alles immer persönlich

Nochmals zum Verständnis, mein Problem:

1. einmal kurz Verbindung gestört, dann wird jegliche weitere Verbindung mit dem gleichen ConnectString verweigert!!!!!!!

Lösung hier bei der ADO Connection:

2. Connected auf False setzen (Trennen)

3. ConnectString Leeren

4. ConnectString wieder auf ursprung setzen

5. Connected auf True setzt nun geht wieder alles.

Schritte 2-5 möchte ich nicht, das ist meine Frage/ mein Problem!

Im Programm nach einem Hänger muss es genau an der Stelle weitergehen wo es gehangen hat!

Durch die Vielzahl der Möglichkeiten, was der user gerade treibt xxx DataSet auf (MDI-Fenstern) besteht keine Möglichkeit genau das wieder zur Ansicht zu bringen was gerade in der Bearbeitung ist.

[Bernhard Geyer]

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.

Wenn du deine MDI-Formuarle wieder genau an die Stelle bringen willst musst du den Zustand sichern (Bookmark auslesen und nach Reconnect wieder setzen).
Falls das nicht klappt den Primärschlüsselwert des aktuell markierten Datensatzes lesen und wieder setzen.

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