Portable Version verschwindet beim Öffnen einer GEDCOM-Datei

[Flominator]

Hallo zusammen, nachdem ich heute mit getmyancestors.py aus einem FamilySearch-Zweig eine GEDCOM-Datei erzeugt habe, wollte ich sie mir in Ahnenblatt portable 2.98 anschauen. Allerdings scheint es, als stürzt die Anwendung nach einem Drittel der Datei (ganze Datei hat 1.5 MB) ohne Fehlermeldung o.Ä. ab.

Gibt es irgendwo ein Log, eine Konsole o.Ä., mit der ich herausfinden kann, an welcher Stelle das Problem liegt?

Ein generelles Problem ist es nicht, weil es bei kleineren Beispielen funktioniert hat.

Danke und Gruß,
Flo

[Fridolin]

Keine Ahnung. Das wäre aber sicher ein Thema, das Dirk auch interessieren könnte. Der scheint jedenfalls einen Debug-Modus zur Verfügung zu haben. Wäre die Frage, ob du ihm die Datei zum Testen zur Verfügung stellen würdest.

Wie wär's ansonsten mit dem GEDCOM Validator, um die Datei mal auf ihre Konsistenz/Standard-Treue zu prüfen? Kenn ich mich aber auch nicht mit aus.

Frido

[Flominator]

Wenn ich mit einem Skript die im Validator angezeigten zu langen Texte beschneide, bekommt er die Datei zumindest ohne Absturz importiert, wenn er auch eine Warnung anzeigt, dass die Datei nicht vollständig ist.

Anbei eine der Dateien, die den Absturz verursacht haben, sowie deren Variante mit abgeschnittenen Kommentaren. Sie wurden, wie erwähnt mit https://github.com/Linekio/getmyancestors erzeugt. Dort habe ich unter https://github.com/Linekio/getmyancestors/issues/2 auch schon einen entsprechenden Defect erzeugt.

Dennoch halte ich es für suboptimal, dass das Programm einfach abstürzt. Vielleicht kann Dirk ja etwas dagegen tun, ich pinge ihn mal an.

[Fridolin]

Na, zumindest will der Macher des Tools sich der Sache annehmen - das ist doch auch schonmal was:

FlominatorTM: Can you please do something about this?

Linekio: Yes I can. I had never found software that does not support long lines before.

(https://github.com/Linekio/getmyancestors/issues/2)

Frido

[DirkB]

Hallo Flo,

habe mir das gerade mal angeschaut ...

Die Datei enthält bei einer Person eine ca. 2000 Zeichen lange Datumsangabe. Diese bringt Ahnenblatt dann zum Absturz (innerhalb einer GEDCOM-Datum-Konvertierungsroutine).

In der nächsten Programmversion wird diese Datei keinen Absturz mehr erzeugen.

Ansonsten enthält die GEDCOM-Datei diverse Fehler, die in anderen Programmen zu Fehlern bzw. Datenverlusten führen werden (nicht nur überlange Zeilen mit weit über 250 Zeichen).

Diverse Daten an falscher Stelle (z.B. bei Einbürgerung = NATU oder RESI = Wohnort), die wahrscheinlich von allen Programmen ignoriert werden und somit verschwinden (auch in Ahnenblatt).

Viele nicht-GEDCOM-konforme Datumsangaben wie z.B. "DATE 17 August 1706" statt "DATE 17 AUG 1706" oder "DATE von 1735 zu 1770" statt "DATE FROM 1735 TO 1770", die von diversen Programmen ignoriert oder verstümmelt werden (aber nicht Ahnenblatt).

Ich denke, um diese Datei zu reparieren (d.h. alle Daten brauchbar zu machen), wäre wohl viel GEDCOM-Know-How und Fleiß notwendig.

Gruß, Dirk

[Flominator]

Hallo Dirk,

Danke fürs Anschauen. Dass Ahnenblatt da die Grätsche macht, ist schon nachvollziehbar. Ich frage mich dennoch, ob hier nicht ein Logfile/Crashlog (vielleicht mit Zeilennummer) hilfreich wäre, um das Problem selbst zu finden?

Gruß,

Flo

[DirkB]

Hallo Flo,

das schreibt sich immer so leicht ...

Ein Crash kommt immer unerwartet - daher ist es kaum möglich soetwas mitzuprotokollieren.
Ahnenblatt macht auch keine Prüfung auf GEDCOM-Konformität. Ich prüfe also nicht, ob Zeilen oder Datumsangaben länger als erlaubt sind, sondern versuche alles brauchbar einzulesen. Alles andere halte ich für Schlaumeierei ("Habe eine GEDCOM-Ungereimtheit gefunden - konnte die aber augrund genialer Programmierung ausbügeln!"). Dafür sind GEDCOM-Abweichungen einfach zu häufig anzutreffen und der unbedarfte Anwender wird dadurch höchsten verunsichert ...

Daher finden sich unter "Datei / Import Bericht..." selten grobe Fehlerhinweise.

- Dirk

[Flominator]

Ich kenne das zwar nur von c#, aber einen globalen try-catch-Handler mit Ausgabe des Stack-Trace zu implementieren, sollte doch auch in c++ gehen?

[bjew]

"gehen" tut vieles - obs einen realen Nutzen hat?
In einer Firmenumgebung vielleicht, wenn die Entwickler in Reichweite sind und es sich um eine Produktivsystem handelt.
Wieviele Absturzberichte deines Windows-Systems hast du schon aufbereitet, analysiert und/oder an MS weitergeleitet?