Delphi-PRAXiS
Seite 3 von 3     123   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   AnyDAC (FireDAC) - Exception beim schließen einer TADConnection (https://www.delphipraxis.net/195739-anydac-firedac-exception-beim-schliessen-einer-tadconnection.html)

hoika 22. Mai 2018 22:21

AW: AnyDAC (FireDAC) - Exception beim schließen einer TADConnection
 
Hallo,
Zitat:

Habe ich bereits versucht. Bei dem Objekt welches nicht mehr verfügbar ist, komme ich an die Info Name oder ClassName nicht mehr ran.
Dann ist das also schon freigegeben worden, aber die Klasse, die das Objekt enthält, weiß nichts davon.
Normalerweise informiert eine solche Klasse seinen "Visitor", dass sie freigegeben wird.

Hier hilft nur ein Minimalprojekt, was den Fehler verursacht.
Ich denke, sogar FastMM4 hilft hier nicht, weil es nur die 2. Stelle findet,
wo der Zugriff bereits nicht mehr klappt, weil das Objekt nicht mehr existiert.

Viel "Spaß" beim Debuggen (nicht böse gemeint).

Ein Ansatz wäre ein Loggen von ClassName, Name (oder was auch immer sinnvoll ist)
und das schrittweise Ausführen des Codes, um festzustellen,
ab wann das Objekt in der Liste nicht mehr gültig ist.
Ich empfehle eine Logdatei, die immer wieder den Class/Name (was auch immer) aller
Klassen in der Liste schreibt.
Die kann man sich per Notepad++ immer aktuell ansehen.

Cashew 23. Mai 2018 06:17

AW: AnyDAC (FireDAC) - Exception beim schließen einer TADConnection
 
Zitat:

Zitat von hoika (Beitrag 1402707)
Hallo,
Hier hilft nur ein Minimalprojekt, was den Fehler verursacht.
Ich denke, sogar FastMM4 hilft hier nicht, weil es nur die 2. Stelle findet,
wo der Zugriff bereits nicht mehr klappt, weil das Objekt nicht mehr existiert.

Viel "Spaß" beim Debuggen (nicht böse gemeint).

Mit dem "Minimalprojekt" hab ich gestern bekommen und hab schon meinen "Spaß" :lol:


Vielen Dank für Eure Hilfe...

Cashew 7. Jun 2018 13:56

AW: AnyDAC (FireDAC) - Exception beim schließen einer TADConnection
 
Hallo,

nach einiger Zeit des Debuggens haben wir zwei Fehlerursachen gefunden. Meine Testanwendung ist wie folgt aufgebaut:

  • Eine Hauptform vom FormStyle = fsMDIForm.
    Diese Form beinhaltet zwei TDatabase Komponenten (BDE) und zwei TADConnection (AnyDac) sowie Buttons zum Aufrufen von MDI Child Forms

  • Eine MDI Child Form (FormStyle = fsMDIChild). Diese Form arbeitet mit den folgenden Controls (welche natürlich miteinander Verbunden sind):
    • 1x TADTable
    • 1x TDataSource
    • 1x TDBNavigator
    • 1x TDBEdit (dem DateField ist ein Feld vom Typ TStringField zugewiesen)
    • 1x TDBMemo (dem DateField ist ein Feld vom Typ TMemoField zugewiesen [DB Field Typ = Blob])
    • 1x TEdit

    • Die DB Controls sind natürlich miteinander verbunden...


Die hier im Thread beschriebene EAccessViolation tritt auf, wenn mehrfach (2-3 mal) unterschiedliche Datensätze geändert werden und hierbei entweder:
  • in den FetchOptions.Items der TADTable fiBlobs ausgeschlossen wurde
und/oder
  • im TADTable Event BeforeEdit die Methode RefreshRecord aufgerufen wird.
    Anmerkung: Es kommt zu keiner EAccessViolation wenn RefreshRecord an anderer Stelle aufgerufen wird. Zum Beispiel über den Refresh Button des TDBNavigators.

Andere Optionen die in der TADTable verändert wurden (z. B. FormatOptions.MapRules, DetailFields, UpdateOptions.KeyFields, ...) konnten wir ausschließen. Des Weiteren wurden auch in der TADConnection keine besonderen Veränderungen vorgenommen.

Hat jemand eine Idee, warum es durch das ausschließen von fiBlobs aus den FetchOptions.Items, oder durch das Verwenden von RefreshRecords im Event BeforeEdit, zu solchen Problemen kommen kann?
Machen wir vielleicht beim Abrufen der Blob Daten etwas falsch?


Alle Zeitangaben in WEZ +1. Es ist jetzt 20:16 Uhr.
Seite 3 von 3     123   

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz