AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken AnyDAC (FireDAC) - Exception beim schließen einer TADConnection
Thema durchsuchen
Ansicht
Themen-Optionen

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

Ein Thema von Cashew · begonnen am 21. Mär 2018 · letzter Beitrag vom 7. Jun 2018
Antwort Antwort
hoika

Registriert seit: 5. Jul 2006
Ort: Magdeburg
8.277 Beiträge
 
Delphi 10.4 Sydney
 
#1

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

  Alt 18. Mai 2018, 16:18
Hallo,
Zitat:
Nun stellt sich mir die Frage warum der CommandCount falsch ist, oder ein TADCustomCommand Objekt nicht mehr verfügbar ist.
Laß Dir doch von beiden irgendwas eindeutiges anzeigen, ich nehme meist Name oder ClassName.
Das passt hier ja wohl nicht.

Es könnte sein, dass Du irgendein Command-Objekt doppelt freigibst oder "falsch" freigibst.
Was auch immer "falsch" bedeutet.

Kannst Du das ganze Problem nicht mit einer separaten Beispiel-Exe nachvollziehen,
die nur minimalen Code enthält?
Heiko
  Mit Zitat antworten Zitat
MichaelT

Registriert seit: 14. Sep 2005
Ort: 4020 Linz
562 Beiträge
 
Delphi 10.3 Rio
 
#2

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

  Alt 18. Mai 2018, 20:34
Der Fehler kommt nicht von der Stelle. Der kommt von früher. Das Disconnect tut nichts. Die Implementierung ist leer.

Aus irgendeinem Grund ist der Handle auf die DB Session ungültig, vermutlich auf der Serverseite. An sich genügt es, auch wenn es nicht sauber ist die Excpcetion zu bügeln bis die Migration vorbei ist und dann eine passende Client Library zu suchen oder möglw. zuvor.

Es genügt ein isoliertes AnyDAC Beispiel um mal zu zeigen ob die Client Library an sich mal funktioniert. Hernach die BDE dazu tun. Irgendwann mal müsste sich das Phänomen zeigen.

Es gab Fälle in den die die anderen Komponenten einfach sagten, 'Danke und schönen Tag liebe DB'.

Ich kann mich noch an Fälle vor 8 erinnern als die großen Migrationswellen waren, da kam es hie und da vor, dass eine andere Library die Gegenseite.

Das Timeout kann viel sein. In der C-DLL eine Absturz. Die kennen keine Exceptions. Ich vermute am Client tracen hilft. Nach Bauchgefühl wohlgemerkt halte ich das für wahrscheinlicher. Wie du sagst ohne den Code. Wenn das Programm zuvor lief könnte ich mir vorstellen, dass entweder die DB wurde abgegradet oder die Library getauscht oder eine andere wird geholt aus irgendeinem Grund.



Hallo,
Zitat:
Nun stellt sich mir die Frage warum der CommandCount falsch ist, oder ein TADCustomCommand Objekt nicht mehr verfügbar ist.
Laß Dir doch von beiden irgendwas eindeutiges anzeigen, ich nehme meist Name oder ClassName.
Das passt hier ja wohl nicht.

Es könnte sein, dass Du irgendein Command-Objekt doppelt freigibst oder "falsch" freigibst.
Was auch immer "falsch" bedeutet.

Kannst Du das ganze Problem nicht mit einer separaten Beispiel-Exe nachvollziehen,
die nur minimalen Code enthält?
  Mit Zitat antworten Zitat
Cashew

Registriert seit: 15. Mär 2017
24 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#3

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

  Alt 22. Mai 2018, 06:33
Moin Moin...

Hallo,
Laß Dir doch von beiden irgendwas eindeutiges anzeigen, ich nehme meist Name oder ClassName.
Das passt hier ja wohl nicht.
Habe ich bereits versucht. Bei dem Objekt welches nicht mehr verfügbar ist, komme ich an die Info Name oder ClassName nicht mehr ran.

Kannst Du das ganze Problem nicht mit einer separaten Beispiel-Exe nachvollziehen,
die nur minimalen Code enthält?
Das ist jetzt mein nächster Versuch... Wie ganz am Anfang erwähnt, tritt dieser Fehler ja nicht permanent auf. Mittlerweile haben wir zwei Konstellationen über die wir den Fehler provozieren können, hier gilt es nun herauszufinden warum er immer an dieser Stelle auftritt.



Der Fehler kommt nicht von der Stelle. Der kommt von früher. Das Disconnect tut nichts. Die Implementierung ist leer.
Stimmt, der Fehler liegt an einem TADCustomCommand Objekt welches die AnyDAC freigeben möchte, aber nicht mehr verfügbar ist.

Es genügt ein isoliertes AnyDAC Beispiel um mal zu zeigen ob die Client Library an sich mal funktioniert. Hernach die BDE dazu tun. Irgendwann mal müsste sich das Phänomen zeigen.
Die AnyDAC ist funtionsfähig, auch wenn eine BDE dazukommt. Das haben wir über Test Projekte mittlerweile ausgeschlossen...
What goes arround, comes arround
  Mit Zitat antworten Zitat
MichaelT

Registriert seit: 14. Sep 2005
Ort: 4020 Linz
562 Beiträge
 
Delphi 10.3 Rio
 
#4

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

  Alt 22. Mai 2018, 10:34
Gut. Danke für das Feedback. Dann muss ich für den Moment passen.

Moin Moin...
  Mit Zitat antworten Zitat
hoika

Registriert seit: 5. Jul 2006
Ort: Magdeburg
8.277 Beiträge
 
Delphi 10.4 Sydney
 
#5

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

  Alt 22. Mai 2018, 22:21
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.
Heiko
  Mit Zitat antworten Zitat
Cashew

Registriert seit: 15. Mär 2017
24 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#6

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

  Alt 23. Mai 2018, 06:17
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ß"


Vielen Dank für Eure Hilfe...
What goes arround, comes arround
  Mit Zitat antworten Zitat
Cashew

Registriert seit: 15. Mär 2017
24 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#7

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

  Alt 7. Jun 2018, 13:56
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?
What goes arround, comes arround

Geändert von Cashew ( 7. Jun 2018 um 14:20 Uhr)
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 14:17 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz