Exception ohne wirklichen Auslöser treibt mich in den Wahnsinn!

[berens]

Über TAdoQuery und TAdoConnection via Ole/Jet auf eine .mdb Datei. Nicht das was eine professionelle Lösung ist, aber das, womit ich arbeiten muss. Außer in dem Thread selbst verwende ich die Ado-Komponenten nirgendwo, falls das irgendwas zur Sache tut...

[Perlsau]

Zitat von berens:

Über TAdoQuery und TAdoConnection via Ole/Jet auf eine .mdb Datei. Nicht das was eine professionelle Lösung ist, aber das, womit ich arbeiten muss. Außer in dem Thread selbst verwende ich die Ado-Komponenten nirgendwo, falls das irgendwas zur Sache tut...

Womöglich liegt es gar nicht vordergründig an deinem Code oder an den Ado-Komponenten, sondern an einer instabilen Verbindung. Wenn du mal Google nach Verbindung+Netzlaufwerk+Switch+stabil fragst, kommst du der Sache vielleicht näher. Zumindest ich hatte ähnliche Probleme beim Einrichten einer Terminverwaltung für drei Arbeitsplätze ohne Datenbank-Server. Die Daten der drei Arbeits-PCs sollten eigentlich immer auf ein via Switch angeschlossenes Netzlaufwerk gespeichert werden. Daß die Verbindung zur Access-DB, die auf dem von allen dreien erreichbaren Netzlaufwerk lag, ständig abriß, zog jedesmal einen Programmabsturz nach sich. Nach dem Austausch des Switch-Controllers war die Verbindung stabil genug, um keine Programm-Abstürze mehr zu verzeichnen. Leider weiß ich heute nicht mehr, von welcher Marke alter und neuer Switch waren ...

Testen könntest du das außer mit Pings, indem du mal probierst, mit eingeschaltetem Cache zu arbeiten: Alle Daten werden erstmal lokal auf dem Rechner gespeichert, danach wird die Verbindung wieder getrennt. Und immer schön Try-Except-Blöcke verwenden, das vermindert die Absturzhäufigkeit im Fehlerfalle

[jensw_2000]

Ich werfe auch noch kurz 3 Aspekte in die Runde...

Bei ADO/dbGo muss jeder Thread, der auf die DB zugreift eine eigene TADOConnection haben.
Sonst funktioniert das Connection Pooling nicht.

Jeder Thread der ADO nutzt muss sein eigenes CoInitialize aufrufen.

Je nach Anwendung würde ich abwägen, ob ich COM ggf. als MULTITHREADED initialisiere.
Das läuft oft runder, wenn dein Programm nicht auf OLE, Clipboard oder Shell Dialoge zugreift.

[Furtbichler]

Ursächlich für diese obskuren Fehler ist der Programmierstil. Er verstößt so ziemlich gegen jedes Gebot der robusten Programmierung: Die Routinen sind zu lang, es werden etwaige auftretende Fehler mit leeren Except-Blöcken einfach unter den Tisch gekehrt (Motto: "Habe keine Ahnung, was hier passiert"). Es wird zwar die Möglichkeit eines Abbruchs kommentiert, aber nirgens umgesetzt (if terminated then exit )

Im Code sehe ich 'FclProjekte'. Sag nicht, das das eine Listbox ist. Wenn ja => garantierte Fehlerquelle. Verwende *nie niemals nicht* ein VCL-Control als Datenstruktur. die VCL-Controls dienen *nur* zum Darstellen von Daten.

Delphi-Quellcode:

 
if blGefunden then begin
  FreeAndNil(tmpProjekt);
end else begin
  Synchronize(SyncNewDataset); // <--- was wird denn hier synchronisiert? 
  FclProjekte.Add(tmpProjekt);
end;

Weiterhin erzeugst Du erst ein TProjekt, füllst es, suchst dann in der Liste nach, ob es schon da ist, schmeisst es wieder weg, wenn ja usw.

Das Suchkriterium ist die ID. Verwende eine Dictionary / Hashmap, um zu prüfen, ob Du die ID schon geladen hast. Wenn ja, gehe zum nächsten Record. Nur wenn die ID noch nicht geladene wurde, instantiierst du ein TProjekt, füllst die Eigenschaften und übergibst das an dein Formular. Weniger Klimmzüge => weniger Fehlerquellen.

Unterteile deine Methode in einzelne Methoden, die genau eine Aufgabe erledigen. Verwende *nie niemals nicht* leere Except-Blöcke, sondern logge alle Exceptions.

Zum Eingrenzen des Fehlers:

1. Kommentiere alles aus. Läuft es? => Weiter mit 2.
2. Aktiviere nur die ADO-routinen, d.h. instantiiere dein TProjekt, fülle es, schmeiss es weg. Läuft es? Weiter mit 3.
3. Aktiviere die Listenlogik (nur, wenn es keine Listbox ist). D.h. suche in der Liste usw. Läuft es? Weiter mit 4.
4. Aktiviere die Synchronize-Methoden eines nach dem anderen.
5. Tja, Keine Ahnung, wenn du hier gelandet bist.

[Blup]

Zitat von Furtbichler:

Im Code sehe ich 'FclProjekte'. Sag nicht, das das eine Listbox ist. Wenn ja => garantierte Fehlerquelle. Verwende *nie niemals nicht* ein VCL-Control als Datenstruktur. die VCL-Controls dienen *nur* zum Darstellen von Daten.

Der Call Stack lässt dies als Ursache vermuten.
Insbesondere der Zugriff aus einem Thread auf eine VCL-Komponente ist ein sicherer Absturzkandidat.

[berens]

Alle cl* Komponenten bei mit sind TComponentList. Von allen Datentypen aus der Datenbank jeweils eine, die NUR im Thread benutzt wird (Fcl*) und eine, die NUR außerhalb des Threads benutzt wird (cl*). Bei SyncNewDataset beispielsweise werden alle neu hinzugekommenen Einträge über Synchronize von Fcl* an cl* Übergeben.

Im Thread verwende ich keine VCL-Komponenten, ADO wurde mit CoInitialize etc. entsprechend vorbereitet.

Nochmal: Das komplette Programm läuft zuverlässig und einwandfrei. Das einzige was "stört" ist die Exception-Meldung ansich. Deshalb die leeren try..except Blöcke rund um allen Quelltext, den ich für den Bösewicht halte. Trotzdem kommt die Meldung weiterhin.

Wie kann ich denn von der Pointer-Adresse aus dem Fehlerlogbuch auf einen Variablennamen (z.B. FclProjekte) kommen, um zumindestens die schuldige Komponente benennen zu können? Ich sehe zwar, dass irgend eine Liste Probleme macht. Aber welche??

Danke schonmal für die Antworten. Ich hoffe wir finden was.

[p80286]

Zitat von berens:

Nochmal: Das komplette Programm läuft zuverlässig und einwandfrei. Das einzige was "stört" ist die Exception-Meldung ansich. Deshalb die leeren try..except Blöcke rund um allen Quelltext, den ich für den Bösewicht halte. Trotzdem kommt die Meldung weiterhin.

"Mein Auto läuft einwandfrei, nur dieses Lämpchen, was aussieht wie eine Ölkanne, das stört. Wie kann man das abschalten.

Das ist die gleiche Logik!
Aber bitte mach ruhig.

Gruß
K-H

[Uwe Raabe]

Zeig doch mal die Deklarationen und Instanzierungen der TComponentList-Instanzen.