"WinAhnen: Ich bin sicher der letzte ..." oder "Das Gedcom-Dilemma"

[ole]

Hallo smatthaeus,

Zitat:

Das Programm arbeitet anscheinend intern schon mit dem Gedcom-Format?

Dann würde ich doch da nicht weiter groß rumzackern und einfach mal versuchen, die Datei mit einem modernen Genealogieprogramm versuchen zu importieren.

Das alte Winahnen hat ein proprietäres Dateiformat. Die Dateien haben die Erweiterung *.ahn.
Es ist in der Lage, einen Gedcom-Export zumachen, wobei ein uraltes Format entsteht. Zudem fehlen etliche Inhalte und manche Felder sind auch nicht konform zum damaligen Standard gefüllt. Damit hat man beim Import in ein neues Programm ziemliche Verluste.
Zum Glück gibt es noch einen Excel-Export, der mehr Daten liefert.
Mein Programm, der WinahnenDatenRetter, versucht aus den beiden Dateien (GED und XLS) eine saubere GEDCOM-Datei im aktuellen Format zu machen und dabei alle möglichen Daten zusammenzufügen und strukturelle Fehler zu beheben.

Die Meldung "Lade Gedcom-Datei: E:\In Arbeit\Winahnen\Konvert\Mattar_2.ged" kommt von meinem Konverter. Es handelt sich dabei um die exportierte Ged-Datei aus dem Winahnen. Klar kann man die woanders auch versuchen aufzumachen, und es wird auch eine gewisse Menge an Daten eingelesen. Jedoch fehlt einiges (was in der Exceldatei steht) und manches andere im Gedcom enthaltene wird Murks (z.B. nicht-exakte Datumsangaben mit Präfixen (vor, nach, ca., um, ...)).

Viele Grüße
Olaf

[Blaubart]

Hallo Paulchen_DD,
das Problem mit der ID 496 hatte ich bereits selber gefunden und korrigiert. Es fehlte der Geburtsname. Deswegen hatte ich überall, wo der Geburtsname fehlt den Namen X1, X2,... eingegeben. Etwa 10 Datensätze waren davon betroffen. Danach dann funktionierte die Korrektur der Verwaltungs-IDs.
Zur Zeit hänge ich noch an der Exception (siehe oben angefügte Datei).
Ich habe bereits mein Testverzeichnis direkt unter das Wurzelverzeichnis E:\ verschoben und aus allen Dateinamen Leerzeichen oder Unterstriche entfernt: Der gleiche Absturz findet noch immer statt.
Bzgl. der Log Datei ist meine obige Antwort nicht ganz korrekt. Nach Absturz wird zwar eine Log-Datei erstellt, sie enthält aber nur Info zur Überprüfung der xlsx-Datei und wieviele Personen und Familien geladen wurden. Danach steht dann nur noch der Zeitpunkt wann die Log Datei geschlossen wurde, nichts bezgl. irgendeines Fehler.

[ole]

Die Leerzeichenproblematik im Verzeichnisnamen sollte man m.E. doch mal testen. Die Fehlermeldung
Lade Gedcom-Datei: E:\In Arbeit\Winahnen\Konvert\Mattar_2.ged
GEDCOM konnte nicht geöffnet werden
deutet mir sehr auf diesen Klassiker hin. Irgendeine Stringoperation (beispielsweise, um den Pfad mit dem Dateinamen zu 'verheiraten'), wo der Programmierer kein Leerzeichen erwartet hat - und crash
Ist bei Entwicklungsumgebungen, CAD-Systemen, Simulationsprogrammen insbesondere aus USA oft passiert (die hatten das nämlich nicht auf dem Schirm programs --> programme myFiles --> Eigene Dateien, dieser potentielle Bug wurde also bei der Internationalisierung von Win hineingebaut). Heutzutage nimmt jeder Programmierer natürlich die speziellen Win-Funktionen für Manipulationen von Pfaden etc. - aber unter Win 7 habe ich diesen Bug definitiv noch mehrfach gesehen. Aber Du als Programmierer des Tools wirst das sicherlich besser einschätzen können.
Viele Grüße
Paulchen

Die Meldung "Lade Gedcom-Datei: E:\In Arbeit\Winahnen\Konvert\Mattar_2.ged" kommt aus meinem Prorgamm. Das alte Winahnen ist da schon durch. Mit Winahnen exportiert man zuvor zwei Dateien, eine Gedcom und eine Excel. Wenn es das geschafft hat, dann kommt mein Programm aus 21. Jahrhundert auch mit langen Dateinamen und Leerzeichen klar.

[ole]

Hallo Blaubart,

Zuvor hatte ich bereits einen Duchlauf gemacht, bei dem ohne weitere Fehlermeldung ca. 2300 Fehler der IDs korrigiert worden sind. In der Original-Datei hatte ein Großteil der Einträge die gleiche ID. Danach dann beim nächsten Durchlauf war der Absturz mit Exception.

In der Tat hast du dann nicht sogar eine alte Winahnen-Datenbank sondern eine wirklich sehr alte. Das mit den Reparieren der IDs ist genau dann nötig. Danach beide Dateien neu exportiert? Mit der Exception warst du dann einen Schritt weiter. Das Reparieren hatte dann offensichtlich geklappt.

Weder eine Ergebis-Datei noch ein Eintrag im Log waren danach erzeugt.
Woran kann ich denn erkennen, dass mit dem Datensatz Nr 1496 etwas nicht stimmt? Es war das größte Problem, dass ich nicht idenifizieren konnte, wo genau der Absturz passiert ist.
Ich werde mich wieder melden, wenn ich weiter gekommen bin oder noch Fragen habe.
Zunächst erstmal herzlichen Dank für die Hilfe!

Wenn du nicht weiter kommst, kann ich dir auch anbieten, dass du per Privatnachricht mir deine Mailadresse zur Kontaktaufnahem mitteilst. Dann kannst du mir mit dem nötigen Vertrauenm die Datei schicken und ich kann dann in die Fehlersuche tiefer einsteigen.

Ich sehe gerade, dass der Bezug zu Datensatz Nr 1496 sich auf meinen ersten Eintrag hier im Forum bezog. Diesen Fehler konnte ich selber korrigieren, da einige EInträge keinen Gerurtsnamen hatten. Diesen habe ich dann durch X1, X2,... ersetzt. Danach dann ist der erste Durchlauf zur Korrektur der Verwaltungs-ID ohne Probleme gelaufen.

Klassiker sind wie gesagt Schrägstriche bei den Namen. Fehlender Nachname dürfte weniger das Problem sein. Vielleicht in Kombination mit der Angabe des Rufnamens? Müsste ich eben als konkrtene Fall haben, was da steht.

Viele Grüße
Olaf

[Blaubart]

Es geht vorwärts!
Den Grund für den Absturz habe ich finden können sozusagen durch "binäres Kürzen" der originalen GED-Datei vom Ende her. Der Grund war ein Hochkomma in einem Vornamen.
Leider kam dann die nächste Exception allerdings mit einer komplett anderen Meldung:

System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.

Danach dann der Dump mit dem Inhalt des Calling-Stack.

Ich denke, ich suche am besten auch wieder wie gehabt. Dazu dann noch im Log Hinweise: Leider sind vor Geburtsdatum und Todesdatum immer ein * oder + geschrieben. Das verhindert ein vernünftiges Erkennen des Datums. Dazu muss ich leider jeden Eintrag korrigieren...

[ole]

Leider sind vor Geburtsdatum und Todesdatum immer ein * oder + geschrieben. Das verhindert ein vernünftiges Erkennen des Datums. Dazu muss ich leider jeden Eintrag korrigieren...

Vielleicht klappt es, vor dem Konverterlauf in der Excel-Datei in den betreffenden Spalten die * und + zu entfernen.

[Paulchen_DD]

Vielleicht klappt es, vor dem Konverterlauf in der Excel-Datei in den betreffenden Spalten die * und + zu entfernen.

Dazu vielleicht noch der Hinweis, dass die Ersetzen-Funktion mit dem + sicherlich problemlos automatisch für die ganze Tabelle funktioniert.
Beim * ist es etwas anders, normalerweise ist * ein Wildcard für beliebig viele Zeichen. Deshalb hier nach ~* suchen und dieses durch (nichts) ersetzen lassen
Viel Erfolg!
Paulchen

[Blaubart]

Ich habe jetzt alle Sonderzeichen, die nicht akzeptiert worden sind, im Original (Kopie) gelöscht, trotz der doch recht umfangreichen Arbeit, weil noch so einige andere Korrekturen bzgl. Beziehungen und fehlernder Verknüpfungen bzgl. Heirat nötig waren. Nach jedem Export der Exel Tabelle hätte ich ansonsten auch immer wieder die Zeichen vor dem Datum löschen müssen.
Jetzt läuft alles einwandfrei ohne Absturz und Fehlermeldung. Durch das Datenrettungsprogramm habe ich auch einige Beziehungen zwischen Personen mit gemeinsamen Kindern einpflegen können, die vorher nicht definiert waren.

Zusätzlich zum ged-Format habe ich aus Excel das csv-Format exportiert. Damit bin ich flexibel genug für einen Import z.B. in eine Datenbank (SQL).
Ein bestimmtes neues Programm zur Verwaltung der Ahnen habe ich noch nicht gefunden. Da diese Daten mehrere Generationen überleben sollten, suche ich ein Programm, das qelloffen ist (Public Domain) und nach Möglichkeit nicht auf ein bestimmtes Betriebssystem zugeschnitten ist. Das größte Problem sehe ich dabei mit der grafischen Benutzeroberfläche. SQL Datenbank-Software gibt es quelloffen.
Wahrscheinlich ist es nur eine Wunschvorstellung. Die Alternative wäre, alles selbst zu programieren (abgesehen vom Aufwand wäre es kein Problem für mich).

Ich danke Allen, die mir mit Rat geholfen haben, besonders ole für sein wirklich nützliches Progarmm.

Da ich jetzt weiß, wie ich mögliche Fehler in den Daten finden kann, werde ich jetzt die nächste AHN-Datei in Angriff nehmen. Der Stammbaum meiner Frau geht nachweisbar bis 1200 zurück. Das sind auch wieder einige tausend Datensätze. Mal sehen, auf welche Probleme ich damit stoße....

[ole]

Hallo Blaubart,
schön zu hören, dass du irgendwie durchgekommen bist. Viel Glück mit der nächsten Datei.
Der Thread hier ist sicher nicht der richtige für Softwareempfehlung. Generell würde ich persönlich nicht was neues schreiben. Da hängt zu viel dran.In meinen Augen das wichtigste: ein vollständiger Import/Export im (nicht zu altem) Gedcom-Format. Gramps könnte was für dich sein. Sehr mächtig. Läuft nicht nur unter Windows. An die UI konnte ich mich aber nicht so richtig gewöhnen. Persönlich würde ich nie was mit einer Onlineplattform für die eigenen Daten anfangen.
Viele Grüße
Olaf
PS: Deine PN habe ich bekommen. Ich antworte mal bei Gelegenheit.