Hallo zusammen,
ich kenne bislang weder Pro-s-AHN noch die von Pro-s-AHN erzeugten DBF-Dateien.
Ich habe aber ein ganz ähnlich gelagertes Problem mit dem Programm GenProfi gehabt. GenProfi hat einen sehr lückenhaften und zum Teil fehlerhaften GEDCOM Export, bietet aber intern extrem viele Möglichkeiten, Daten zu strukturieren. Mit GenProfi werden hervorragende Ortsfamilienbücher und Familiendatenbanken gepflegt, deren Daten dann aber sehr lückenhaft und zum Teil fehlerhaft über die GEDCOM Schnittstelle in den Online-OFB ankamen. GenProfi arbeitet mit Access-Datenbanken und speichert seine Daten überwiegend in DBF Dateien. Es ist gar kein Problem, solche Dateien z.B. mit EXCEL zu öffnen. Aber der Weg dann zu einer vollständigen, korrekten GEDCOM ist weit, sehr weit. Man muss die gesamte Logik der Datenablage eines Programmes in diesen Dateien verstehen, um daraus eine GEDCOM zu machen. Im Fall GenProfi z.B. werden Namen, Vornamen, Orte usw. in eigenen Tabellen geführt und dann aus einer Datei heraus verlinkt, in der die Zusammenhänge dargestellt sind. Sämtliche Ereignisse haben eigendefinierte Abkürzungen und Strukturen in GenProfi, die alle den entsprechenden GEDCOM Konstruktionen zugeordnet werden müssen. Zum Zeil sind die Bedeutungen dieser GenProfi-Ereignisse dann sogar noch abhängig von den in ihnen gespeicherten Werten.
Für den Fall GenProfi habe ich einen Modul entwickelt und über längere Zeit optimiert, der die in GenProfi gespeicherten Daten vollständig in korrektes GEDCOM umwandelt. Das waren mehrere Wochen harte Arbeit, um dieses Ergebnis zu erhalten.
Ich fürchte, auch für Pro-s-AHN würde der Aufwand nicht geringer sein. Denn ein Programm, welches keinen GEDCOM Import oder Export hat, wird sich ähnlich wie GenProfi nicht an der in GEDCOM definierten Datenstruktur orientieren, sondern komplett eigene Strukturen nutzen.
Vor dem Hintergrund empfehle ich zu prüfen, ob Pro-s-AHN die Möglichkeit bietet, halbwegs strukturierte Berichte zu exportieren. Wenn diese eine erkennbare systematische Struktur aufweisen, ist es evtl. einfacher, einen Parser zu bauen, der diese Berichte interpretiert und in GEDCOM überführt. Auf dem Weg habe ich einige nur in WORD-Dateien zur Verfügung stehende OFB in die GEDCOM-Welt geholt, um dann daraus Online-Veröffentlichungen zu machen. Dieser Weg ist von der Programmierarbeit sicher schneller, führt aber auch dazu, dass für eine wirklich gute Aufteilung der Daten in die Datenfelder eines GEDCOM-Programmes dann noch Nacharbeit gemacht werden muss. Wenn sehr viele oder extrem große Dateien aus der Pro-s-AHN Welt nach GEDCOM geholt werden sollen, könnte dieser Weg wiederum aufwändiger werden…
Das Beispiel zeigt einmal mehr, dass bei der Auswahl eines Programmes unbedingt darauf geachtet werden sollte, dass die im Programm gespeicherten Daten vollständig nach GEDCOM exportiert werden können. Ansonsten sitzt man schnell in der Falle, dass man die Daten zwar alle sauber eingegeben hat, aber mit ihnen dann nicht das machen kann, was man machen will!
Viele Grüße
Albert (Emmerich)