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.