Ahnenblattportal

bjew hat geschrieben:

Marcus hat geschrieben:...
* Für die Jüngeren: das war mal eine flotte Art mit der Bahn zu reisen In der Vor-ICE-Zeit

Ja ja, Spitzenreisegeschwindigkeit 160, allwettertauglich - also auch bei Schnee, Regen und Wind - und
pünktlich!.
Sprichwörtlich pünktlich wie die Eisenbahn

Ja ja, ihr zwei Scherzpolde. Also dir Bernhard glaube ich ja noch den D-Zug (Diesel Zug) erlebt zu habe. Aber Marcus dir nicht mehr ganz, bei dir war es wohl der IC oder EC.
So jung bin ich auch wieder nicht. Und bei uns in Austria gibt es nur wenige ICE's und die Eisenbahn ist auch oft PÜNKTLICH. Vielleicht liegt es ja wirklich am deutschen Qualitätsprodukt ICE.
Schluß mit dem Abschweifen in die Urzeiten der Eisenbahn und den Anfeindungen

Also Marcus, sei kein Regionalzug, her mit den Fehlernummern oder der Diskusion.

Ciao
Alexys

Hallo Alexys,

nicht nur Diesel- sondern noch Dampf-Zug. Damit war ich schon in meinen ältesten Erinnerungen stundenlang unterwegs.

Und Anfeindungen sind das doch nicht, nur Tatsachenfestellungen.

Na ja, die Feldpostnummer oder besser die Zug-Nummer ändert gar nichts an der Bearbeitung durch Dirk. Es geht damit sicher weder schneller noch langsamer - und verloren geht auch ohne Nummer nichts.
Die Nummer ist lediglich ein zusätzliches Hilfs- und Ordnungsmittel innerhalb des Forums.
Also Eile mit Weile - mit oder ohne Nummer (womit die Themaabschweifung wieder beendet wäre).

Hallo Alexys,

Die durch Deine Vorarbeit erkannten zwei Fehler sind beschrieben. Herzlichen Dank dafür

Die sich darüber hinaus ergebenden Probleme sind darauf zurückzuführen, dass Deine CSV-Testtabelle in sich (gewollt) fehlerbehaftet ist. Es kann aber nicht Aufgabe von Ahnenblatt sein, alle möglichen Fehler, die in Fremd-Programmen oder Fremd-Tabellen vorhanden sind, beim Import zu erkennen und zu eliminieren. In der Regel ist davon auszugehen, dass die Daten auch in Fremd-Tabellen weitgehend in Ordnung sind, so dass der Import nach Ahnenblatt keine zusätzlichen Probleme verursacht. Ich gehe davon aus, dass das nach Beseitigung der erwähnten zwei Fehler höchstwahrscheinlich auch so sein wird.

Weit wichtiger - als der doch seltene Import fremder Daten - ist für uns User, dass der Export von Ahnenblatt in eine CSV-Tabelle und der Reimport einer nachbearbeiteten CSV-Tabelle nach Ahnenblatt fehlerfrei läuft. Durch die komfortablen Bearbeitungsmöglichkeiten in Programmen wie Excel, Access, o. ä. lassen sich Erfassungsfehler finden, die einem in den Einzelansichten von Ahnenblatt kaum auffallen würden.

Es steht aber jedermann frei, ein Programm zu schreiben, mit dem man auch interaktiv Fehler und Ungereimtheiten in einer CSV-Tabelle (à la Ahnenblatt) eliminieren kann.

Punto e basta!

Hallo Torquatus!

Torquatus hat geschrieben:Die durch Deine Vorarbeit erkannten zwei Fehler sind beschrieben.

Es waren doch mal 4 Probleme.

Torquatus hat geschrieben:Es kann aber nicht Aufgabe von Ahnenblatt sein, alle möglichen Fehler, die in Fremd-Programmen oder Fremd-Tabellen vorhanden sind, beim Import zu erkennen und zu eliminieren.

Tut mir leid da bin ich aber anderer Meinung:
Es ist nur eine Sache der sauberen Programmierung die Inkonstistenz der Daten zu erkennen. Aber bitte. Wenn die aufgestellt Beschreibung von Dirk gilt, gibt es dann eh kein Problem mehr.

Torquatus hat geschrieben:Weit wichtiger - als der doch seltene Import fremder Daten - ist für uns User, dass der Export von Ahnenblatt in eine CSV-Tabelle und der Reimport einer nachbearbeiteten CSV-Tabelle nach Ahnenblatt fehlerfrei läuft.

Voll deiner Meinung.

Alexys Rex hat geschrieben:
Werden aus einer CSV Datei leer SURN oder GIVN eingelesen werden die 3 Punkte nicht ergänzt. (Ob das sinnvoll ist weiß ich nicht, jedoch der Einheitlichkeit wegen.)

Wurde meine neue Beitrag ignoriert oder ergibt sich das aus deinem 2.Problem?

Ciao
Alexys

Hallo Alexys,

DirkB hat geschrieben:CSV-Import: Handling von Namensfeldern optimiert

als ich das las, hoffte ich, dass Dirk mit der neuen Version 2.62 auch die von Dir gefundenen Fehler beseitigt hat. Aber über diese Änderung bin ich ja gar nicht glücklich

Diese Einklammerungen bemerkt man ja (anders als hier mit dem Testfile; siehe unten) überhaupt nicht. Da wäre es besser, er würde ein Importprotokoll erstellen, in dem solche Problemfälle gelistet werden.

Torquatus hat geschrieben:

DirkB hat geschrieben:CSV-Import: Handling von Namensfeldern optimiert

als ich das las, hoffte ich, dass Dirk mit der neuen Version 2.62 auch die von Dir gefundenen Fehler beseitigt hat. Aber über diese Änderung bin ich ja gar nicht glücklich

Komisch, denn ich finde die Lösung genial ...

... nämlich aus folgenden Gründen:

1. Es gehen keine Namens-Informationen mehr verloren.
2. Es erscheinen keine Informationen mehr im gleichen Feld doppelt.

Klammern werden übrigens nur in folgenden Fällen eingefügt:

1. Die Spalte NAME enthält nur ein einzelnes Wort. Dann wird dieses Wort in Klammern als Geburtsname eingetragen (kann ja auch ein Vor- oder Spitzname sein).
2. Das letzte Wort in Spalte NAME stimmt nicht mit SURN überein. Dann wird der unter NAME gefundene Nachname in Klammern gesetzt.
   Habe ich selbst mal so gefunden, wobei bei weiblichen Personen unter SURN der Geburtsname und unter NAME der Familienname zu finden war.

Gruß, Dirk.

------------------------------
#Wunschliste_839_ERLEDIGT_V2.69

Hallo Dirk,

DirkB hat geschrieben:

Torquatus hat geschrieben:

DirkB hat geschrieben:CSV-Import: Handling von Namensfeldern optimiert

als ich das las, hoffte ich, dass Dirk mit der neuen Version 2.62 auch die von Dir gefundenen Fehler beseitigt hat. Aber über diese Änderung bin ich ja gar nicht glücklich

Komisch, denn ich finde die Lösung genial ...

... nämlich aus folgenden Gründen:
1 [*]Es gehen keine Namens-Informationen mehr verloren.
2 [*]Es erscheinen keine Informationen mehr im gleichen Feld doppelt.

die Lösung ist schon komplett, daran zweifel ich ja auch nicht

Aber die Fälle müssen nachbearbeitet werden und dafür ist die Kennzeichnung mittels Klammerauf+Klammerzu nicht gerade ideal, vor allem dann, wenn auch anderweitig Klammern verwendet wurden. Naja, da gebe ich mich geschlagen , auch mit anderen "Sonderzeichen" zur Kennzeichnung hätte man die gleichen Probleme.

Dankbar, wie wir nun mal sind, können wir nur das nehmen, was wir bekommen

Die Hilfe sagt bisher:

NAME - Der Name der Person im Format "Vornamen Geburtsname". Hat man bereits eine Familienliste in einer Tabellenkalkulation eingefügt, dann evtl. nur mit zusammenhängenden Namen, die Ahnenblatt dann selbstständig in Vornamen und Geburtsname trennt. Diese Spalte ist überflüssig und wird ignoriert, wenn es eigene Spalten für Vornamen (GIVN) und Geburtsnamen (SURN) gibt.

Mein Vorschlag zur Änderung:

NAME - Der Name der Person im Format "Vornamen Geburtsname". Hat man bereits eine Familienliste in einer Tabellenkalkulation eingefügt, dann evtl. nur mit zusammenhängenden Namen, die Ahnenblatt dann selbstständig in Vornamen und Geburtsname trennt. Diese Spalte ist überflüssig und wird ignoriert, wenn es eigene Spalten für Vornamen (GIVN) und Geburtsnamen (SURN) gibt. Sind trotzdem alle drei Spalten vorhanden und sind deren Inhalte widersprüchlich, dann kennzeichnet Ahnenblatt diese Fälle indem die widersprüchlichen Namensteile in Klammern () gesetzt werden. Diese Fälle sollte man daher mit der Funktion "Suchen" suchen (also nach "(" suchen) und nachbearbeiten.

Vielleicht kann sich auch mal kurz Alexys dazu äußern.
Er hatte das Thema ja ursprünglich aufgebracht ...

Gruß, Dirk.

Hallo Dirk!

Vielen Dank für die schnelle Erledigung des Fehlerhinweises.

DirkB hat geschrieben: Komisch, denn ich finde die Lösung genial ...

... nämlich aus folgenden Gründen:

1. Es gehen keine Namens-Informationen mehr verloren.
2. Es erscheinen keine Informationen mehr im gleichen Feld doppelt.

Ich finde von genial ist es noch etwas entfernt. Denn folgende Überlegung meinerseits.
Es gibt noch folgende Fälle die ich besser gelöst vorstellen könnte:

1. Das Grundproblem warum ich den Fehler entdeckt habe ist nicht sauber gelöst. Also erkläre ich ihn dir nochmals. Bei Fall 14 ist der GIVN und der NAME identisch. Jedoch wird dann bei Vorname der GIVN eingetragen und bei Geburtsname nun in Klammer der NAME eingetragen.
   Ich schlage vor auch einen Vergleich zwischen GIVN und NAME zu machen. Damit lässt sich auch Fall 7 lösen.
   Dies geschied übrigens beim Fall 5 eh schon automatisch.
2. Übrigens ist dies auch ein möglicher Export Import Fehler, wenn im Geburtsname nichts eingetragen ist. Ich weiß passiert je eh nicht, da es die 3 Punkte (...) gibt. Aber siehe auch Diskusion oben über das 2.Problem mit den 3 Punkten (...)! Dies ist in dieser Version 2.62 nicht gelöst.

DirkB hat geschrieben: Klammern werden übrigens nur in folgenden Fällen eingefügt:

1. Die Spalte NAME enthält nur ein einzelnes Wort. Dann wird dieses Wort in Klammern als Geburtsname eingetragen (kann ja auch ein Vor- oder Spitzname sein).
2. Das letzte Wort in Spalte NAME stimmt nicht mit SURN überein. Dann wird der unter NAME gefundene Nachname in Klammern gesetzt.
   Habe ich selbst mal so gefunden, wobei bei weiblichen Personen unter SURN der Geburtsname und unter NAME der Familienname zu finden war.

Mit der Klammerlösung kann ich leben, begeister bin ich jedoch nicht.

1. Bei Fall 10 würde ich auch beim Vorname Klammern setzten. bzw. ich finde Benutzerabfragen bei Problem auch einen gangbaren Lösungsweg, vielleicht mit einem "anhaken" Feld "immer übernehmen" bei größere Datenmengen. Abfrage könnte z.b. lauten "NAME oder GIVN mit SURN bevorzugen?" Antworten "NAME", "GIVN mit SURN" und "BEIDE".
2. Wenn nur im NAME nur ein Wort eingegeben ist und unter SURN und GIVN nichts würde ich keine Klammer setzen, siehe Fall 3, Fall 4.
3. Über Fall 15 lässt sich noch diskutieren, jedoch würde ich keine setzen. Somit würde ich dein Punkt 1 Streichen. Mit der Begründung das vielleicht in GIVN ein Rufname oder Spitzname stehen könnte. Ein weiters Argument gegen die Klammer ist auch die einheitliche Behandlung von Unterschieden bei Fall 12 und Fall 13 erfolgt auch keine Klammersetzung obwohl der SURN Fehlt.
   
   Über eine Vornamenerkennung im NAME-feld nachzudenken ist wohl eine Illusion oder? Bei Fall 4 und Fall 17 wäre dies der Fall (natürlich geht dieser nicht). Jedoch wenn ein Nachname wie ein Vorname ist geht dies nicht mehr.
   Gut wenn nur ein Wort in NAME-feld ist, wie wäre es mit einer Abfrage?
   
   Das Problem mit den 3 Punkten ist ja noch nicht gelöst!!!
   Meine Meinung zu den 3 Punkten ist sie nur "IMAGINÄR" zu halten. Also nicht immer die echten 3 Punkte ergänzen.

Ich würde mich über eine weitere Diskusion freuen, bevor weitere Schnellschüsse gemacht werden. Natürlich sind meine Eingaben bewußt fehlerhaft gewesen und einige Fälle treten wahrscheinlich nie auf.

Ich habe nun insgesamt 19 Eingabemöglichkeiten gefunden habe den alten Fall 18 geändert (da doppelt - Fall 7) und eine 19. Fall gefunden. Siehe Anhänge

Ciao
Alexys

Alexys Rex hat geschrieben:Ich finde von genial ist es noch etwas entfernt. ...

Ich schrieb genial, nicht optimal. Optimierungpotential ist immer noch vorhanden ...

Unklare Textteile in Klammern zu setzen, finde ich trotz allem einen guten Kompromiss.

Ich werde mal schauen, wie ich deine Verbesserungsvorschläge umgesetzt bekomme.

Alexys Rex hat geschrieben: Ich würde mich über eine weitere Diskusion freuen, bevor weitere Schnellschüsse gemacht werden. ...

Als "Schnellschuss" würde ich die jetzige Umsetzung keineswegs bezeichnen ...

Hier in der Diskussion wurde bislang auch nur auf die Fehlersituationen hingewiesen, ohne einen Lösungsvorschlag zu bringen. Ich hatte auch nicht das Gefühl, dass es noch dazu gekommen wäre ...

Klar, kann ich zu allen aufkommenden Themen immer bohrend nachfragen, wie denn eine Lösung gewünscht wird, aber das führt auch nur immer bedingt zum Ziel und kostet letztlich Zeit, in der vielleicht schon längst eine brauchbare Lösung fertig wäre.

Gruß, Dirk.

Alexys Rex hat geschrieben:

• Übrigens ist dies auch ein möglicher Export Import Fehler, wenn im Geburtsname nichts eingetragen ist. Ich weiß passiert je eh nicht, da es die 3 Punkte (...) gibt. Aber siehe auch Diskusion oben über das 2.Problem mit den 3 Punkten (...)! Dies ist in dieser Version 2.62 nicht gelöst.

Das habe ich übrigens nicht nachvollziehen können ...

Ich lasse bei der Eingabe entweder Geburtsname oder Vornamen leer.
Dann als CSV speichern und die Spalten bleiben leer.
Dann die CSV wieder öffnen und die Eingabefelder sind immer noch leer - wie bei der Eingabe (zugegeben: bei leerem Geburtsnamen musste ich die Spalte NAME löschen).

Ahnenblatt zeigt zwar im Navigator oder Listen/Tafeln drei Punkte, aber das war nicht das Problem, oder ...?

Gruß, Dirk.

Hallo Dirk!

Dank für deine rasche Antwort.

Ich wüßte nicht ob Lösungsvorschläge zu Problem erwünscht sind und wie konkret diese sein können. Daher erst im nachhinein eine genauer Beschreibung. Ich wollte mich nicht unbedingt in dein Programm einmischen und habe daher nur Optimierungspotential aufgezeigt.
Bei meinen 20 Eingabemöglichkeiten in CSV ergeben sich folgende Fälle:

1. Alles ist gleich also Fall 5: Damit lässt sich dann auch Fall 7, Fall 8, Fall 11, Fall 12, Fall 14 und Fall 18 lösen.
2. Alles unterschiedlich also Fall 10: Damit lässt sich dann auch Fall 6, Fall 9, Fall 16, Fall 17, Fall 18 lösen. z.B.: Deine Klammerlösung oder eine Abfrage
3. Es fehlen Eingaben bei NAME oder GIVN mit SURN: Sofern die nicht schon in den verhergehenden Punkten enthalten sind würde ich die von dir vorgeschlagene ergänzende Form verwenden. Bleibt auso nur Fall 15.
4. Eingabe nur in GIVN oder SURN. Fall 1, Fall 2 und Fall 20
5. Eingabe nur in NAME. Fall 3, Fall 4 und Fall 13: Stellt nur ein Problem dar wenn es ein Vorname sein sollte, wie Fall 4. Dieses ist jedoch nicht so einfach zu lösen. Daher lassen wie es jetzt ist oder eben eine Vornamenerkennung oder am besten eine Abfrage.

Also max. 5 Abfragenmöglichkeiten, denn Punkt 3, 4 und 5 könnte man evntuell zusammenfassen. Ich hoffe, dass ich dir damit nicht zuweit in den Programmierkompetenz eingegriffen habe.

Also nur zu Problem der 3 Punkte:

DirkB hat geschrieben: Ahnenblatt zeigt zwar im Navigator oder Listen/Tafeln drei Punkte, aber das war nicht das Problem, oder ...?

Das war nicht das Problem sondern ist die Lösung!

DirkB hat geschrieben:

Alexys Rex hat geschrieben:

• Übrigens ist dies auch ein möglicher Export Import Fehler, wenn im Geburtsname nichts eingetragen ist. Ich weiß passiert je eh nicht, da es die 3 Punkte (...) gibt. Aber siehe auch Diskusion oben über das 2.Problem mit den 3 Punkten (...)! Dies ist in dieser Version 2.62 nicht gelöst.

Das habe ich übrigens nicht nachvollziehen können ...

Ich fasse mal die Diskusion mit Zitaten zusammen.

Torquatus hat geschrieben:nana, versuche es doch einfach. Erfasse eine Person nur mit Vorname und lasse den Nachnamen leer. Nach dem Verlassen des Erfassungsfensters oder nach Betätigung des OK-Buttons stehen dann im Nachnamen die drei Punkte. Ehrlich

Alexys Rex hat geschrieben:Gut machen wir den Versuch:
Muß mich korrigieren: Geht nur nicht, wenn man neue Person verwendet. (Wohl wieder ein BUG - Sorry)
Neue Person - Eingabe von Alexys als Vorname - OK klicken - und am Bildschrim sind die von mir als "imaginäre" 3 Punkte (...) bezeichneten Punkte.
Nur klicken wir auf den Edit Button und Geburtsname ist leer.
Gut dann eben gleich Speichern unter CSV gehen und auch hier bleibt SURN leer.

Torquatus hat geschrieben:Bei einer Neuanlage fehlen tatsächlich die Punkte. Dieser Fehler ist wohl bisher nicht aufgefallen (vielleicht auch erst in die neueste Version geraten). Jetzt weiß ich auch, wie der Eine (ohne Punkte) in meine Datei kam Dieser Fehler sollte beseitigt werden.

Torquatus hat geschrieben:Beide Fehler sollten in die Fehlerliste aufgenommen werden.
Vorschlag für die Schlagtexte:
- Fehler beim NAME-Import von CSV-Daten bei leerem SURN
- Bei der Neuanlage einer Person ohne Nachname fehlen die Punkte

Falls es jetzt noch nicht klar geworden ist, beschreibe ich nun nochmal das Problem.

Es gibt zwei Eingabemöglichkeiten:

1. Neue Person: immer am Anfang nötig. Person editieren Fenster. Keine 3 Punkte in leeren Vornamen oder Geburtsnamen.
2. Über anklicken eines Feldes in Verwandtenbereich z.B. Vater oder Kinder. Schnell Eingabefenster, nur Vornamen und Geburtsname. Es werden echte 3 Punkte in leeren Vornamen oder Geburtsnamen ergänzt.

Somit sollte jetzt das Probem nachvollziehbar sein.
Lösungsvorschlag:
Ich würde Veriante 2 einfach mit dem Schnell Eingabefenster einfach durch den Person editieren Fenster ersetzen. Vielleicht hat sich da die echten 3 Punkte Ergänzung eingeschlichen oder erhalten geblieben.
Bei leerem Feld ist Einfacherklick neue Person Person editieren Fenster, anderenfalls wie bisher ist ein Einfacherklick Person vorsetzen und auswählen.
Bei Doppelklick auf ausgewählte Person Person editieren Fenster, damit würde auch der Bleistift-Button (Personen Editieren) unnötig und könnte entfernt werden.
Bei leerem Feld ist Einfacherklick neue Person eingeben, anderenfalls wie bisher ist ein Einfacherklick Person vorsetzen und auswählen.

Gut soviel zu meinen Vorschlägen, die sogar nun in die Bedinung eingreifen würden. Ich hoffe auch hier, dass ich dir damit nicht zuweit in den Programmierkompetenz eingegriffen habe.

Ciao
Alexys