FireDAC Fehler? #2

[haentschman]

Hallöle...8-)

Callstack:

Zitat:

exception message : Zugriffsverletzung bei Adresse 00B5261E in Modul 'SEAM.exe'. Lesen von Adresse 000000B8.

main thread ($2508):
00b5261e +01e SEAM.exe FireDAC.DatS TFDDatSRow.InternalSetData
02d22e93 +02f SEAM.exe DMEdit 7829 +3 TDMED.SetDateName
02c9470a +06a SEAM.exe Form.Assignment 1083 +2 TfoAssignment.GridEdStoNeuDBTableViewAktuellDblCli ck
0096b518 +1a0 SEAM.exe cxControls 8368 +21 TcxControl.WndProc
00ead7c2 +03a SEAM.exe cxGridCustomView 5424 +3 TcxGridSite.WndProc
02d93c91 +d59 SEAM.exe SEAM 328 +217 initialization

Der Quelltext dazu:

Delphi-Quellcode:

procedure TDMED.SetDateName(DataSet: TDataSet);
begin
  if DataSet.State = dsEdit then // !!!!!
  begin
    DataSet.FieldByName('ixRecName').AsString := USER_KN; // Zeile 7829 ist die hier
    DataSet.FieldByName('RecDate').AsDateTime := Now;
  end;

  if DataSet.State = dsInsert then
  begin
    DataSet.FieldByName('ixAddName').AsString := USER_KN;
    DataSet.FieldByName('AddDate').AsDateTime := Now;
  end;
end;

...das sind Stellen an die man normalerweise nicht dran geht. :?

Hat das eine Verbindung mit https://www.delphipraxis.net/198316-firedac-fehler.html?

[hoika]

Hallo,
gibt es den das Feld ixRecName im DataSet überhaupt?
Das sieht doch wie ein Nil-Zugriff aus.

Ist DMEdit Dein DataModul?

[haentschman]

Moin...8-)

Zitat:

Ist DMEdit Dein DataModul?

Ja. Alle Querys sind darauf und sind automatisch erzeugt oder beim FormShow aktiviert.

Zitat:

gibt es den das Feld ixRecName im DataSet überhaupt?

Ja. Das Feld existiert in allen Datenmengen die vom User bearbeitbar sind.

Zitat:

Das sieht doch wie ein Nil-Zugriff aus

...ja eben. Aber selbst ein NULL Feld erzeugt keine Zugriffsverletzung. Wenn ein Feld nicht existiert gibt es eine vernünftige Meldung. :?

PS: Die procedure wird hundere Male am Tag aufgerufen. :roll:

[hoika]

Hallo,
nein, ich meinte

Delphi-Quellcode:

DataSet.FieldByName('ixRecName').AsString

DataSet.FieldByName('ixRecName') ist nil, wenn es das Feld ixRecName nicht gibt.
Dann erzeugt nil.AsString eine Zugriffsverletzung.

Mach doch mal explizit eine Abfrage

Delphi-Quellcode:

if DataSet.FieldByName('ixRecName')=nil then
begin
  // ShowMessage  irgendwas
end;

Zitat:

Querys sind darauf

Per Select * oder direkt als Select Field1,Field2?

Zitat:

Die procedure wird hundere Male am Tag aufgerufen

Also tritt das Problem nur sporadisch auf?

[haentschman]

Zitat:

Also tritt das Problem nur sporadisch auf?

richtig...Ich hab nur so sporadischen Schei...

Zitat:

DataSet.FieldByName('ixRecName') ist nil, wenn es das Feld ixRecName nicht gibt.

...da gehe ich ich noch mit, aber

Zitat:

Wenn ein Feld nicht existiert gibt es eine vernünftige Meldung.

...seit wann gibt es eine Zugriffsverletzung wenn ein Feld in der Datenmenge nicht existiert? :gruebel:

[Uwe Raabe]

Zitat:

Zitat von hoika (Beitrag 1416609)

DataSet.FieldByName('ixRecName') ist nil, wenn es das Feld ixRecName nicht gibt.

Das stimmt so nicht! Im Gegensatz zu

Delphi-Quellcode:

FindField

liefert

Delphi-Quellcode:

FieldByName

niemals ein

Delphi-Quellcode:

nil

zurück, sondern erzeugt vorher eine

Delphi-Quellcode:

EDatabaseError

Exception.

[DasWolf]

Hallo,

kommt der Fehler auch, wenn Du einen anderen Wert zuweist oder ein

Delphi-Quellcode:

DataSet.FieldByName('ixRecName').Clear

machst?

[haentschman]

Danke...

Zitat:

Also tritt das Problem nur sporadisch auf?

Das ist genau das Problem. Ich kann nicht sagen ob das funktioniert oder auch nicht. :?

Zitat:

PS: Die procedure wird hundere Male am Tag aufgerufen.

PS: Für mich wäre interessant ob das an den Daten liegen kann oder ob die Komponente querschießt.

[Frickler]

Sicher, dass die Fehler-Zeile die richtige ist? Möglicherweise ist ja "DataSet" nil. Dann rummst es eine Zeile drüber...

[haentschman]

Zitat:

Möglicherweise ist ja "DataSet" nil. Dann rummst es eine Zeile drüber...

:wink: Wie soll er dann diese Zeile kommen?

Zitat:

00b5261e +01e SEAM.exe FireDAC.DatS TFDDatSRow.InternalSetData

[Frickler]

Stimmt auch wieder :oops:

Hat die verwendete Query Komponente zur Designzeit eingerichtete persistente Felder? Ich hatte hier schon "interessante Effekte" wenn die aktuell abgefragten Werte (aus welchem Grund auch immer) nicht zu den persistenten Feldern passen.

[haentschman]

Zitat:

zur Designzeit eingerichtete persistente Felder?

Meines Wissens nicht.

[hoika]

Hallo,
wenn es sporadisch kommt, mache das doch so, wie ich es vorgeschlagen habe (ShowMessage).
Und dann testen, testen, testen.

Du könntest auch noch FastMM4 und MadExcept mit ins Boot nehmen.

[Hobbycoder]

Wenn bei mir so ein Fehler immer nur sporadisch auftritt, dann schreibe ich mir alle Werte, die in den betreffenden Zeile / procedure verwendet werden (möglicherweise auch NIL od. nicht NIL) stumpf in eine Logdatei. Solange bis der Fehler auftritt. In den meisten Fällen hat mir das schon sehr geholfen. Möglichweise steht ja in USER_KN was drin, was das DataSet bzw. FireDac so gar nicht beißen kann. USER_KN scheint ja eine globale Variable zu sein. Wenn die mal nicht initialisiert ist(aus welchen Gründen auch immer), können da schon mal tolle Sachen drin stehen ;-) Und dann such man den Fehler an dieser Stelle vergebens.

Showmessage ist zwar ganz schön, kann aber gerade bei sporadischen Fehler echt nerven ;-)