Access Violation - OnFilterRecord - UniDAC

[Ritsch]

Hallo.

Unsere Software wurde bisher mit RAD Studio XE7 entwickelt.
Jetzt möchten wir auf 10.1 Berlin umsteigen und stoßen dabei auf ein erhebliches Problem.
Wir verwenden die UniDAC DB-Komponenten.

An unserem TUniTable arbeiten wir dem Event "OnFilterRecord".

Dort ist bspw. folgender Code

Delphi-Quellcode:

begin
  inherited;
    Accept:= (DataSet.FieldByName('D10B00000_Aktiv').AsInteger = 1);
    Accept:= (Accept and (StrToInt64Def(DataSet.FieldByName('D10B00000_ModulNr').AsString, -1) = Self.oMyD11D00000Config.iModulNr));
    Accept:= (Accept and (StrToInt64Def(DataSet.FieldByName('D10B00000_ModulUnterNr').AsString, -1) = 1));
end;

Dieser Code funktioniert tadellos wenn ich das Projekt mit XE7 erstelle.

Unter 10.1 Berlin bekomme ich nun allerdings eine Access Violation, allerdings erst beim zweiten Öffnen eines Datensatzes.
D.h. ich öffne das Programm bzw. das Modul, öffne einen Datensatz und das Event arbeitet korrekt.
Schließe ich jetzt den Datensatz und öffnen den gleichen oder einen anderen Datensatz erneut, bekomme ich eine Access Violation.
Wenn ich vorher das komplette Modul schließe und wieder öffne, funktioniert es wieder beim ersten Datensatz.

Irgendwelche Tipps?

Gruß

[mkinzler]

In welcher Zeile tritt die AV auf?

[Ritsch]

Delphi-Quellcode:

Accept:= (DataSet.FieldByName('D10B00000_Aktiv').AsInteger = 1);

[himitsu]

Ist da die Exception oder steht da nur der Cursor, nach der Exception? (der Cursor steht oft gern im nachfolgenden Befehl)

Zitat:

Delphi-Quellcode:

inherited;

Ist eure Form vererbt und passiert daher eventuell was im inherited?
Wenn nicht vererbt, dann macht inherited nix, da es im Vorfahren keine gleichnamige Methode gibt.


Statt

Delphi-Quellcode:

DataSet

darf man hier auch gern

Delphi-Quellcode:

TDataSet(Sender)

oder

Delphi-Quellcode:

(Sender as TDataSet)

verwenden, denn da steht immer das richtige DataSet drin.

Zitat:

Delphi-Quellcode:

.AsInteger = 1

Delphi-Quellcode:

.AsBoolean

kommt doch auch mit Integern klar? (nur als Hinweis, abber hier erstmal egal)
Aber wenn, dann würde ich hier sicherheitshalber eher

Delphi-Quellcode:

.AsInteger <> 0

anstatt

Delphi-Quellcode:

.AsInteger = 1

verwenden.

[Ritsch]

Delphi-Quellcode:

(Sender as TDataSet)

Kann ich leider nicht verwenden, da:

Delphi-Quellcode:

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:

Delphi-Quellcode:

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:

Zitat von Aviator (Beitrag 1351662)

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

Delphi-Quellcode:

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 :wink:

[Aviator]

Zitat:

Zitat von Ritsch (Beitrag 1351824)

Zitat:

Zitat von Aviator (Beitrag 1351662)

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

Delphi-Quellcode:

if assigned

zu arbeiten, allerdings ohne Erfolg.

Naja gut.

Delphi-Quellcode:

Assigned()

prüft aber nur, ob die Variable nicht

Delphi-Quellcode:

nil

ist. Wenn die Variable aber noch auf ein Objekt zeigt welches mal existiert hat, aber mit

Delphi-Quellcode:

Free

freigegeben wurde, dann gibt dir

Delphi-Quellcode:

Assigned()

trotzdem true aus.

Himitsu hat ja gemeint, dass

Delphi-Quellcode:

FieldByName

selbst auf

Delphi-Quellcode:

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.