Zugriffsverletzung beim erstellen eines Datamoduls

[Delbor]

Hi zusammen

Die Fehlermeldung:

Zitat:

---------------------------
Im Projekt HomeOfficerFEProject.exe ist eine Exception der Klasse $C0000005 mit der Meldung 'access violation at 0x008f8a29: read of address 0x00000090' aufgetreten.
---------------------------

Und der Ausllöser, die erste zeile:

Delphi-Quellcode:

procedure TDMLSQLiteOfficerFE.DataModuleCreate(Sender: TObject);
begin
  Self.FDMoniFlatFileClientLink1.Tracing := False;
  Self.FDMoniFlatFileClientLink1.FileName := ExtractFilePath(Application.ExeName) + '\trace.txt';
  Self.FDMoniFlatFileClientLink1.Tracing := true;
end;

Und wiedermal: Ich finde nirgendwo im Embarcadero Wicki Angaben darüber, für was dieses Objekt gut ist. Den einzigen Hinweis lieferte mir LEO (tracing wird offenbar mit dokumentieren/verfolgen gleichgesetzt...)

Umsomehr: das bewusste Objekt wurde zur Entwurfszeit gesetzt, hat keinen Activ-Schalter, und somit gibts für diese AV auch (scheinbar)keinen Grund.
Was, zum Kuckuck, mache ich falsch??

Gruss
Delbor

[TiGü]

FDMoniFlatFileClientLink1 ist ungleich nil?
Wenn nein, dann ist das Rätsel schon gelöst.

[Delbor]

Hi Tigü

Zitat:

FDMoniFlatFileClientLink1 ist ungleich nil?
Wenn nein, dann ist das Rätsel schon gelöst.

Du meinst, ich müsste das Ding zur Laufzeit erzeugen? Oder was verstehe ich jetzt falsch?

Gruss
Delbor

[Uwe Raabe]

Zitat:

Zitat von Delbor (Beitrag 1501424)

Ich finde nirgendwo im Embarcadero Wicki Angaben darüber, für was dieses Objekt gut ist.

Ich schon: Ablaufverfolgung und Überwachung (FireDAC)

Zitat:

Zitat von Delbor (Beitrag 1501424)

Delphi-Quellcode:

procedure TDMLSQLiteOfficerFE.DataModuleCreate(Sender: TObject);
begin
  Self.FDMoniFlatFileClientLink1.Tracing := False;
  Self.FDMoniFlatFileClientLink1.FileName := ExtractFilePath(Application.ExeName) + '\trace.txt';
  Self.FDMoniFlatFileClientLink1.Tracing := true;
end;

Kann es sein, dass das Datenmodul von einem anderen abgeleitet ist und hier einfach ein inherited fehlt?

[himitsu]

ExtractFilePath hat bereits einen \ am Ende. Wozu dann nochmal einen dazwischen?
Als einfaches Lösung gibt es seit Längerem TPath.Combine.

Und wie wäre es, wenn man langsam mal lernt, wie der Debugger in Grundzügen zu benutzen ist?

Zitat:

FDMoniFlatFileClientLink1 ist ungleich nil?

Die Frage würde man sich dann selber beantworten können und jemand wüsste auch, wo weiter zu suchen ist.


Der Name FDMoniFlatFileClientLink1 klingt ja eher danach, als wenn die Komponente auf dem/der Datamodul/Form liegen sollte (im FormDesigner), was sie scheinbar nicht tut.


@Hersteller
Wenn die Hilfe absolut nichts zu sagen hat, was CodeInsight nicht auch schon kennst, dann darf die Hilfe auch gleich ganz gelöscht werden.
https://docwiki.embarcadero.com/Libr...FileClientLink

[Delbor]

Hi Uwe Raabe

Zuerst mal vielen Dank für den interessanten Link!!

Zitat:

Kann es sein, dass das Datenmodul von einem anderen abgeleitet ist und hier einfach ein inherited fehlt?

Das Projekt ist nicht mehr ganz taufrisch. Von daher könnte es schon sein,das ich mal ein Datenmodul unter anderem Namen abgespeichert habe. Doch normalerweise erzeuge ich auch Datenmodule immer neu und popiere bewährten Code hinein. Trotzdem hab ich mal das inherited eingefügt - mit demselben Ergebnis.

@himitsu: Ich hab jetzt nur gerade mitgekriegt, dass du geposted hast und kurz mal reingeschaut:

Zitat:

ExtractFilePath hat bereits einen \ am Ende. Wozu dann nochmal einen dazwischen?

Zitat:

'/ /'

Das wäre also eine Lücke im Pfad. Nur schade, dass das nicht die ursache war.

Zitat:

Der Name FDMoniFlatFileClientLink1 klingt ja eher danach, als wenn die Komponente auf dem/der Datamodul/Form liegen sollte (im FormDesigner), was sie scheinbar nicht tut.

Eben doch. Und deswegen hab ich erst auch nach sowas wie Active oder Enabled gesucht.


Gruss
Delbor

[Uwe Raabe]

Der Link erwähnt auch diesen Schritt:

Zitat:

Fügen Sie den Verbindungsdefinitionsparameter MonitorBy=Xxx hinzu.

Ist dies denn bei der betreffenden Connection gewährleistet? Ich würde es zwar auch für einen Fehler halten, wenn es ohne dies kracht, aber wir versuchen ja erstmal das ganze zum Laufen zu bringen.

Kannst du denn im Debugger (mit Debug-DCUs) sehen, wo genau das Problem liegt?

[Delbor]

Hi zusammen

Meine Schritte beim Debuggen :
Programmstart mit F9
Anhang 54839
Beim Datamodul.Create mit F7
Anhang 54840
und hier weiter bis zur ersten Boolean-Zuweisung - dann knallts.
und Self ist nil...
Anhang 54841

Gruss
Delbor

[himitsu]

Wieso rufst DU das OnCreate des DataModuls auf?

Und warum hat vorher niemand das Datenmodul erstellt?

[Delbor]

Hi himitsu

Zitat:

Zitat von himitsu (Beitrag 1501439)

Wieso rufst DU das OnCreate des DataModuls auf?

Das mache ich eigentlich immer so, da beim Create einiges zu erledigen ist. Aber dank dir habe ich da mal nachgesehen - es ist tatsächlich unter den automatisch erstellten Formularen...

Gruss
Delbor

[hoika]

Hallo,
das DM wird als erstes erzeugt?

[himitsu]

Diese Events rufen die Forms/DatenModule selbst auf, denn genau dafür gibt es diese Events.

Wenn du sowas aufrfst würde alles doppelt/mehrfach gemacht, was nicht gut sein kann. (z.B. würde FReportList doppelt erstellt, aber nur einmal freigegeben)
Und wenn es vorher nicht von den Modulen aufgerufen wird, dann hast DU etwas falsch gemacht, wie z.B. vergessen es zu erstellen.

In deinem Fall würde ich dir dringend anraten auch mal sowas wie ReportMemoryLeaksOnShutdown auf True zu setzen.

[Delbor]

Hi zusammen

Zitat:

Zitat von hoika (Beitrag 1501441)

Hallo,
das DM wird als erstes erzeugt?

Nein, erst nach der Mainform, da es in den Projektoptionen bei den automatisch erstellten Formularen nach der Mainform aufgeführt ist. Euren Reaktionen entnehme ich, dass ein Datenmodul auch ohne Eintrag unter Projektoptionen/Formularen automatisch vor der Mainform erzeugt würde. Nur - ein solcher Eintrag sagt mir, ob und wie ich das Modul und enthaltene Objekte behandeln muss.

Zitat:

Zitat von himitsu (Beitrag 1501442)

Diese Events rufen die Forms/DatenModule selbst auf, denn genau dafür gibt es diese Events.

Basisframes werden vor der Mainform erstellt. Forms werden aber keineswegs automatisch erstellt, es sei denn, dies wird in den Projektoptionen so festgelegt.* Dass Datenmodule auch ohne Eintrag in den PO automatisch erzeugt werden, habe ich bisher nicht gewusst.

Zitat:

Zitat von himitsu (Beitrag 1501442)

Wenn du sowas aufrfst würde alles doppelt/mehrfach gemacht, was nicht gut sein kann. (z.B. würde FReportList doppelt erstellt, aber nur einmal freigegeben)
Und wenn es vorher nicht von den Modulen aufgerufen wird, dann hast DU etwas falsch gemacht, wie z.B. vergessen es zu erstellen.

In deinem Fall würde ich dir dringend anraten auch mal sowas wie ReportMemoryLeaksOnShutdown auf True zu setzen.

Grundsätzlich verwende ich ReportMemoryLeaksOnShutdown. Es sei denn, ich möchte in einem kleinen Testprogämmchen was testen - und wenn das kleine Testprogrämmchen dann grösser wird...

* Eine Ausnahme ist die erste Form eines Projektes; diese wird automatisch zur Mainform und ebensio automatisch erstellt.

Gruss
Delbor

[himitsu]

Es wird nur das automatisch erstellt, was in den Projektoptionen eingestellt ist,
also genauer das, was in der .DPR via Application.CreateForm erstellt wird. (deswegen werden genau diese Codezeilen von den Projektoptionen generiert)

Aber egal, du kannst nichts verwenden, was es (noch) nicht gibt, sonst knallt es nunmal.
Ob es nun autmatisch erstellt wird, oder ob du es manuell erstellst, ist irrelevant ... es muß aber vor der Verwendung erstellt worden sein.
Und das Event an OnCreate, oder Dergleichen, ruft dann das DatenModul selbst auf, wenn es erstellt wird, nicht du. (wenn du es aufrufen mußt, damit irgendwas funktioniert, dann machst du definitiv etwas falsch)




PS: Auch globale Variablen (Zeiger auf Forms/Module), sind grundsätzlich "immer" erst nach Create/OnCreate gültig.
Einzige Ausnahmen sind die globale Variablen von automatisch erstellten Forms/Datenmodule, oder wenn man selbst mit NewInstance arbeitet und dann den Constructor anschließend selbst wie eine Przedur aufruft. (genau deswegen gibt es Application.FormCreate, damit während des Erstellens von Foms/Modulen andere Forms/Module und Code auf diese Variablen/Namen referenzieren/zugreifen können)

[hoika]

Hallo,
hm, das DM wird also nach dem Hauptform erzeugt.

Hoffentlich wird dann nicht schon im FormCreate des Hauptforms
was mit dem DM gemacht, z.B. irgendwelche Config-Sachen...

Setz mal in der DPR 2 Breakpoints auf die beiden CreateForms-Zeilen ,