Access Violation - OnFilterRecord - UniDAC

[Ritsch]

(Sender as TDataSet) Kann ich leider nicht verwenden, da:procedure (DataSet: TDataSet; var Accept: Boolean)
Wir verwenden das Event so gut wie in allen Modulen, überall tritt dieser Fehler auf.
Z.B. auf hier:
Accept:= (FieldAsInt64(DataSet.FieldByName('D41400000_ID')) <> Self.iCurrID); Bin mal mit F7 in die Funktion FieldAsInt64 gegangen. Habe ein Snip in den Anhang gesetzt.

[Aviator]

Zugriffsverletzungen erscheinen nur dann, wenn auf eine nicht (mehr) existente Instanz zugegriffen wird. In dem Fall ist Field wohl nil. Jetzt gilt es, herauszufinden wieso das der Fall ist.

[himitsu]

FieldByName prüft aber, ob das TField existiert und gibt nur dann den Zeiger zurück. Sonst wirft es eine "ordentliche" Exception.

FindField macht das Gleiche, aber bei Nichtexistenz gibt es nil zurück.

[hoika]

Hallo,
wenn der Fehler immer kommt,
ist das doch ein schöner Punkt für ein "Minimalbeispiel".
Nimm eine lokale Variable für das FieldByName -> MyField.
Was ergibt z.B. MyField.Name im WatchFenster?

Was ich nie verstanden habe, ist, warum man solchen Code schreibt,
ohne eine lokale Variable zu benutzen.
Das macht doch das Debuggen soviel einfacher!

[Ritsch]

Zitat von Aviator:

Zugriffsverletzungen erscheinen nur dann, wenn auf eine nicht (mehr) existente Instanz zugegriffen wird. In dem Fall ist Field wohl nil. Jetzt gilt es, herauszufinden wieso das der Fall ist.

Das ist mir bewusst, was die AV aussagt.
Daher habe ich schon probiert vorher mit if assigned zu arbeiten, allerdings ohne Erfolg.

Zitat:

Hallo,
wenn der Fehler immer kommt,
ist das doch ein schöner Punkt für ein "Minimalbeispiel".
Nimm eine lokale Variable für das FieldByName -> MyField.
Was ergibt z.B. MyField.Name im WatchFenster?

Siehe Anhang.

Zitat:

Was ich nie verstanden habe, ist, warum man solchen Code schreibt,
ohne eine lokale Variable zu benutzen.
Das macht doch das Debuggen soviel einfacher!

Das ist Geschmackssache bzw. wie man es gewohnt ist zu arbeiten

[Aviator]

Zitat von Ritsch:

Zitat von Aviator:

Zugriffsverletzungen erscheinen nur dann, wenn auf eine nicht (mehr) existente Instanz zugegriffen wird. In dem Fall ist Field wohl nil. Jetzt gilt es, herauszufinden wieso das der Fall ist.

Das ist mir bewusst, was die AV aussagt.
Daher habe ich schon probiert vorher mit if assigned zu arbeiten, allerdings ohne Erfolg.

Naja gut. Assigned() prüft aber nur, ob die Variable nicht nil ist. Wenn die Variable aber noch auf ein Objekt zeigt welches mal existiert hat, aber mit Free freigegeben wurde, dann gibt dir Assigned() trotzdem true aus.

Himitsu hat ja gemeint, dass FieldByName selbst auf Assigned() prüft. Vielleicht passiert dann ja im Hintergrund noch was. Gibst du das DataSet irgendwo wieder frei? Bspw. in einem Timer Event oder so? Nicht das sich da etwas beist.

[Ritsch]

Nach langer Analyse bin ich etwas weitergekommen bzw. konnte ich das Verhalten jetzt analysieren.

Beim ersten Aktivieren wird das Event einmal aufgerufen, .RecordCount gibt die korrekte Menge zurück, alles gut.

Beim zweiten bzw. erneuten öffnen wird das Event so oft aufgerufen wie die Anzahl der Records. Das kann schon mal nicht stimmen.
D.h. im ersten Versuch haben ich einen RecordCount = 0, beim zweiten RecordCount = 1 usw.

Das Event wird ja unmittelbar nach dem Aktivieren der Table/Query bzw. gibt es in meinem Fall kein Event was noch anderweitig behandelt wird.
Ich schätze mal das es ein Bug in der UniDAC-Komponente ist, anders kann ich mir das im Moment nicht erklären.

[mkinzler]

Hast Du die neueste Version der Komponenten? Hast Du den Fehler dem Hersteller gemeldet?

[Ritsch]

Unter 10.1 Berlin habe ich die neueste Version.
Fehler wurde bereits gemeldet, ich melde mich sobald ich neue Informationen habem.

[Ritsch]

Habe den Fehler jetzt "behoben" in dem ich beim Table bzw. Query die Eigenschaft Filtered auf False setze, dann das Table/Query aktiviere und dann Filtered wieder auf True setze.
Es scheint ein Timing-Problem zu sein.