SIGSEGV / Stack-Overflow beim Öffnen einer TDBF

[ManniSt]

Nach dem Aufruf eines neuen Formulars und dem Öffnen einer DBF in diesem neuen Formular erscheint immer ein Fehler SISEGV in Lazarus und ein Stack-Overflow bei der Ausführung der Anwendung außerhalb von Lazarus.
Das Ganze läuft unter Win 10.

Identische Aufrufe von 2 anderen Formularen erzeugen keine Fehler.

Woran kann das liegen?
-------------------------------------------------------------------
Aufruf aus Formular TF_Menu:

procedure TF_Menu.Men_ModulesClick(Sender: TObject);

begin
MModulNr := Module.Fields.FieldByName('NR').Value;
Module.close;

F_Menu.Visible := false; // Aufrufende Form auf unsichtbar
F_Modules := TF_Modules.Create(Nil); // Neue Form wird erstellt
F_Modules.ShowModal; // Neue Form wird angezeigt
FreeAndNil(F_Modules); // Neue Form wieder freigeben
F_Menu.Visible := true;
// usw. …
end;

Neues Formular TF_Modules mit dem Fehler bei Module.Open:

procedure TF_Modules.FormCreate(Sender: TObject);

begin
Module.FilePathFull := Modules_Lw;
Module.ReadOnly := false;
Module.Open; // Hier entsteht der Fehler
Module.IndexName := 'NR';
end;

[Lemmy]

was ist "Module"? Soll das ein Dataset sein?

[ManniSt]

Korrekt. Da sind in anderen Formularen auch entaprechende Datasets, wo aber alles funktioniert.

[ManniSt]

Korrekt. Da sind in anderen Formularen auch entaprechende Datasets, wo aber alles funktioniert.

[Lemmy]

und das Dataset liegt auf dem Formular? Wenn nein, wo wird das erzeugt?

[ManniSt]

Das Dataset liegt natürlich auf dem erzeugten Formular.

[img]d:\temp\f_modules.jpg[/img]

[Lemmy]

was passiert, wenn du zur Designzeit die notwenidgen Einstellungen am DataSet im Objektinspektor machst und dort auf Active=true setzt? auch ein Fehler? Was wenn du dort eine andere Tabelle einstellst?

Nachtrag: Irgend welche Events am DataSet aktiv?

[ManniSt]

Das ist interessant. Weise ich dem TDBF eine andere DBF zu, funktioniert es.
Ich habe auch die fragliche dbf umbenannt: Kein Erfolg
Ich habe die fragliche DBFf verschoben und umbenannt: Kein Erfolg

[Winni]

Hallo!

Ich hab vor "hundert Jahren" auch mal dBase-Tabellen ausgelesen um sie anderweitig zu importieren.

* Fallstrick 1: Es werden nur Tabellen bis Version dBase IV angenommen.
dBase V will er nicht

* Fallstrick 2: TDBF geht mal stur davon aus, dass alle Daten heil sind. Da kann ein kaputtes Record den ganzen Salat erzeugen den Du hast.
Lösung: mal in dbase III+/IV sehen, ob alle Datensätze heil sind. Einfach mal im Loop alle Datensätze anzeigen lassen. (Oder in FoxPro)

Falls nix hilft: dBase-Daten OHNE Index sind recht trivial zu lesen. Da fliegen auch diverse Ansätze für Delphi/Lazarus im Netz rum. Komliziert wird es erst beim Index. Das sind balancierte Beyer-Bäume und da haben die meisten aufgegeben.

Aber: Den Index kann man sich ja wieder bauen, wenn die Nutzdaten gerettet sind.

TDBF ist ein ziemlicher Verhau.
Wenn Du noch irgendwo Delphi hast mit der BDE dann nimm das, exportiere die Daten und steck sie in irgendeine SQL DB. Sag ich nicht gerne als Lazarus-Fan.

Winni

[af0815]

Es ginge auch ein Versuch mit ZEOS. Damit die Daten einlesen und wieder wegschreiben. ZEOS ist manchmal robuster bei alten Desktopdatenbanken. Damit braucht man auch keine BDE und Delphi.

[wp_xyz]

Ganz von Anfang an: Kannst du die dbf-Datei in einem ganz simplen Testprogramm öffnen, das lediglich TDBF, TDataSource und meinetwegen ein TDBGrid enthält? Wenn ja, dann liegt der Fehler irgendwo in deinem eigenen Programm.

[ManniSt]

Ja, mit WinDBU. Die Indexdatei (.mdx) ist auch aktiv.
Ebenso mit dem alten Clipper-DBU (natürlich außer .mdx) in einem DOS-Fenster.

Werde aber nocheinmal die dbf mit WinDBU neu erzeugen und dann erst ohne mdx und dann mit mdx testen.

Ich denke mal, dass tatsächlich die dbf defekt ist, da eine andere dbf funktioniert.

[ManniSt]

Es war nicht eine defekte dbf. Ich habe die komplett neu erstellt und immer das Gleiche.

Habe jetzt das Formular noch einmal ganz von vorne und frisch erstellt und da geht es bis jetzt. Weiß der Henker, was das war.