Ahnenblattportal

Hallo Cleo

Wenn du nun die CSV Datei aus dem Versuch 1 mit dem Export von Access aus Versuch 2 in einem Editor anschaust, kannst du da Unterschiede entdecken? Schau dir die gleichen 5 Personen mal genauer an.

Gruss
Roger

Hallo Roger,

habe ich gemacht.
Alles Daten sind identisch.
Das einzige, was mir auffiel war: die Kopfzeile.
In der *unbearbeiteten csv" steht im Editor
"REFN";"NAME";"SURN";"GIVN";"FATH.NAME";"FATH.REFN";"MOTH.NAME";"MOTH.REFN";"SEX";"OCCU";"BIRT.DATE. usw.

Bei der, die ich nach Acces eingelesen und dann wieder exportiert habe, steht:
"REFN";"NAME";"SURN";"GIVN";"FATHNAME";"FATHREFN";"MOTHNAME";"MOTHREFN";"SEX";"OCCU";"BIRT.DATE usw.

Könnte es daran liegen?
Wenn ich das wieder exportiert habe, sind die Punkte weg....

Gruß
Cleo

Guten Tag Petra

cleo33 hat geschrieben:In der *unbearbeiteten csv" steht im Editor
"REFN";"NAME";"SURN";"GIVN";"FATH.NAME";"FATH.REFN";"MOTH.NAME";"MOTH.REFN";"SEX";"OCCU";"BIRT.DATE. usw.

Bei der, die ich nach Acces eingelesen und dann wieder exportiert habe, steht:
"REFN";"NAME";"SURN";"GIVN";"FATHNAME";"FATHREFN";"MOTHNAME";"MOTHREFN";"SEX";"OCCU";"BIRT.DATE usw.

Da liegt das Problem
Der Punkt im TAG fehlt ja überall

Vielleicht hat Roger oder Torquatus ja eine Idee dazu.
Bjew und Marcus hatten sich auch schon mal damit beschäftigt

Ich selber arbeite nur mit D-Base Dateien, deswegen kenne ich mit Access nicht aus
Gruß Hugo

Hallo Hugo,

JA, das scheint der Übeltäter zu sein.
Ich habe jetzt mal einfach mit COPY und PASTE die Kopfzeile im Editor überschrieben, und schon klappes mit dem Einlesen.
Jetzt versuche ich das auch mal bei meiner Riesendatei ;P

Gruß
Cleo

Guten Tag Petra
Da fällt mir noch etwas zu ein (bin aber Access und CSV Laie)
Im Thema: Datei & Gedcom > Gedcom Dateien fehlende Verweise
war ich mal darauf gestoßen, das bei einen RE-Import den Spitzenahnen die Verweise zu den Geschwisternfehlen.

Bjew war damals so nett mal einen Kommentar von Dirk dazu rauszusuchen:

Dirk hat es an anderer Stelle erklärt

DirkB http://www.ahnenblattportal.de/viewtopic.php?t=466&highlight= hat geschrieben: ...

Gedcom verwaltet die Daten und Personenbeziehungen anders als Ahnenblatt und umgekehrt. Ahnenblatt muss also beim Abspeichern Teile der Daten "konvertieren" und beim Re-Import wieder "rekonstruieren". Die Hauptprobleme sind dabei, die Geschwisterbeziehungen und die Datumsfelder.

Gedcom verwaltet die Beziehungen der Personen untereinander in Form von Familien bestehend aus Ehemann, Ehefrau (heißt in Gedcom HUSB und WIFE - unverheiratet ist eigentlich gar nicht vorgesehen) und Kinder. Reine Geschwisterbeziehungen ohne Eltern fallen dabei unter den Tisch. Auf die Schnelle geprüft, sollte eine Gedcom-Familie ohne Eltern noch gedcom-konform sein. Dieses wäre aber beim Speichern aufwändiger zu erkennen und ebenso beim Öffnen. Wenn ich genau darüber nachdenke ist Ahnenblatt überhaupt das einzige Ahnenforschungsprogramm, das ich kenne, dass überhaupt Geschwisterbeziehungen verwaltet ...
...

Nun weiß ich nicht, ob das bei einer CSV-Datei auch passiert.
Das wäre sicherlich fatal für Dich

Ansonsten würde mir aus dem Stand noch dazu einfallen, die exportierte Datei aus Access mit einem Texteditor mit "suchen / ersetzen" zu korrigieren

Den Weg mußte ich damals gehen, als Dirk in Gedcom den TAG CONT neu einführte und das alte Ged2Txt diesen Befehl noch nicht kannte
Gruß Hugo

Hallo Cleo

Jep, hier haben wir vermutlich das Problem: Punkte sind in Access in Feldnamen nicht erlaubt. Beim Import werden die Feldnamen automatisch so angepasst, dass die Daten dennoch ohne Fehler imporiert werden können; der Punkt wird also einfach entfernt.

Funktioniert der Import in AB möglicherweise schon wenn du die Punkte manuell in der CSV Datei einfügst resp. die Headerzeile von einer Original-AB-Export-Datei ersetzt?

Die Vermutung liegt nahe, dass auch andere Datenbank-Programme mit dem Punkt im Feldnamen Probleme haben. Vielleicht wäre Dirk bereit diesen Punkt zu entfernen oder durch einen Bindestrich zu ersetzen... dies natürlich nur, wenn das Tatsächlich die Lösung des Problems ist .

Gruss
Roger

Also ich halte es ja ganz generell nicht für eine gute Lösung eine funktionierende Datei in ein csv-Format zu wandeln, extern zu bearbeiten und dann wieder komplett zu importieren. Mit dem Format provoziert man ja Fehler
Ich halte die Import-Funktion (csv) für ein nettes Gimmick, aber nichts wovon ich das wohl meiner Daten abhängig mache Auch wenn ich in Cleos Fall die Motivation sehr gut verstehen kann
Marcus

Funktioniert der Import in AB möglicherweise schon wenn du die Punkte manuell in der CSV Datei einfügst resp. die Headerzeile von einer Original-AB-Export-Datei ersetzt?

Hallo Roger,

ja, das habe ich gemacht und es hat auch funktioniert.
ABER
Abgesehen davon, dass es ewig gedauert hat, bis meine csv wieder eingelesen wurde ( 72.219 Personen, knapp 20 MB, die Datei)
habe ich jetzt ca. 4900 Plausifehler!
Vornehmlich weil die Verknüpfung bei Mehr-ehen beim Rückimport wohl nicht funktioniert hat. Meldung'Hochzeitsdatum/-ort) nicht identisch.
Ich habe zwar Adam Müller, der einmal mit Anna und einmal mit Adelheid verheiratet ist, nur stehen bei Adam nur ein Name der Ehefrau mit dem Daten/-ort der anderen- und umgekehrt. =()

Manchmal fehlen Ehepartner auch ganz, d.h: in der Ursprungsdatei hatte jemand zwei Ehefrauen, nach Reimport nur noch eine, aber bei der 2. Frau steht die Ehe drin, so dass die Fehlermeldung "fehlender Verweis" kommt...

Gruß
Cleo

Guten Tag
Hab ich doch gesagt.
Ahnenblatt kann in der ahn-Datei mehr, als ALLE anderen.
Jedes Export-Format ist immer nur eine Notlösung.

Ich bin mittlerweile sogar soweit, das ich auch Gedcom-Dateien nicht importieren würde (Habe bisher aber sowieso keine "fremden" Daten importiert).
Lieber schreibe ich es von einer Liste ab und prüfe dabei die Richtigkeit der bekommenen Daten

Den Export benutze ich nur noch für Ged2Txt-Personenblätter.
Gruß Hugo

Hallo Hugo,

jaja, da ist schon was Wahres dran...aber....
ich will doch nur meine Orte *schick* haben...
Und ich bin so ungeduldig...ich warte ja schon, dass Dirk mir meinen Wunsch mit den Orten (ganzen Suchbegriff ersetzen) erfüllt. Dann bin ich rundum glücklich...zumindest was die Ahnensache angeht...

Gruß
Cleo

Hallo,

habe ich jetzt ca. 4900 Plausifehler!
Vornehmlich weil die Verknüpfung bei Mehr-ehen beim Rückimport wohl nicht funktioniert hat. Meldung'Hochzeitsdatum/-ort) nicht identisch.
Ich habe zwar Adam Müller, der einmal mit Anna und einmal mit Adelheid verheiratet ist, nur stehen bei Adam nur ein Name der Ehefrau mit dem Daten/-ort der anderen- und umgekehrt. =()

Manchmal fehlen Ehepartner auch ganz, d.h: in der Ursprungsdatei hatte jemand zwei Ehefrauen, nach Reimport nur noch eine, aber bei der 2. Frau steht die Ehe drin, so dass die Fehlermeldung "fehlender Verweis" kommt...

ich habe das auch mal getestet, obwohl ich so nicht re-importieren würde.

Zunächst ist festzuhalten, dass die CSV-Ausgaben aus Access noch fehlerfrei sind, zumindest habe ich keinen Fehler gefunden.

Beim Import nach AB gehen - gelegentlich - einseitig die Ehe-Angaben und zwar sowohl bei Mehr-Ehen als auch bei Einzel-Ehen. Es gibt auch Fälle, die mit 3 Ehen richtig aus der CSV-Datei zurück-importiert wurden, also scheint es kein spezieller Fehler NUR bei Mehr-Ehen zu sein.

Die meisten Probleme machten aber bei meinem Test die Daten ohne Tag, also die in der Form MM.JJJJ. Die sehen nach dem Export aus Access wie folgt aus: aus 05.1904 wurde 51904 und so wurde das auch dann nach AB importiert.

Gruß, Torquatus

Hallo zusammen

Achtung! Access schaut beim Import von Daten die ersten x Datensätze an und entscheidet dann welches Datentyp-Format wohl am passendsten ist. Ist dies ein Datum, wird ein Datumsfeld vorgeschlagen. Wenn aber erst im Datensatz 5000 ein Datum im Format '05.1880' auftaucht, Access aber nur bis Datensatz 1000 sucht, wird dies knallhart in ein Datum konvertiert. Vielleicht entscheidet Access auch einfach nach dem Typ der am meisten vorkommt... das weiss ich nicht genau.

Da in AB für Datumswerte diverse Eingaben verarbeitet werden können müsst ihr bei Datenbanken für die Datumsfelder IMMER Text oder Varchar auswählen! Auf keinen Fall aber ein Datum!

Was die fehlenden Beziehungen angeht: hier müssen wir vielleicht genauer graben - eventuell hast du hier einen Bug gefunden?! Ich werde heute Nachmittag mal einen Test mit meiner Datei durchführen und die Resultate hier melden.

Gruss
Roger

Hallo Roger,

Achtung! Access schaut beim Import von Daten die ersten x Datensätze an und entscheidet dann welches Datentyp-Format wohl am passendsten ist. Ist dies ein Datum, wird ein Datumsfeld vorgeschlagen. Wenn aber erst im Datensatz 5000 ein Datum im Format '05.1880' auftaucht, Access aber nur bis Datensatz 1000 sucht, wird dies knallhart in ein Datum konvertiert. Vielleicht entscheidet Access auch einfach nach dem Typ der am meisten vorkommt... das weiss ich nicht genau

ich habe mich nicht auf Access verlassen, sondern in den Access-Import-Spezifikationen für die Datumsangaben immer "Text" angegeben. Trotzdem exportiert Acces ein Datum mit dem Text "12.1719" als "121.719". Da helfen auch keine anderen Einstellungen; außer man würde das Feld in Acces in mehrere Felder (tt.mm.jjjj, mm.jjjj, jjjj,usw.) splitten (mit jeweils anderen Formaten) und entsprechend exportieren.

Helfen tut aber schon, wenn man in AB solche Daten als ??.MM.JJJJ erfasst, dann bleiben alle diese Probleme aus.

Gruß, Torquatus

Hallo Torquatus

Ich habe einen Test mit einer kleinen Test-Datei gemacht und dein Datum "12.1719" verwendet. Bei mir hat alles geklappt wie es sollte. Das Datum kommt richtig in die Tabelle und wird auch wieder richtig als Text exportiert. Veränderungen konnte ich keine feststellen.

Was für eine Access Version hast du in Benutzung?

Gruss
Roger