Ahnenblattportal

Ich benutze seit einigen Tagen ( ? ca. 20.8.2018) die Version 3.0 beta6 unter Win10 64bit
Mein Problem neuerdings ist:

von Zeit zu Zeit exportiere ich meine Daten als csv Datei um
1. eine bessere Suchmöglichkeit zu haben
2. in Excel Korrekturen zu machen und dann die korr. CSV Datei wieder zurück zu lesen.

Das hat bisher ( ca. bis Ende Juli 18= vorherige beta-Version) problemlos funktioniert.

Dasselbe habe ich jetzt wieder getan, aber die CSV Datei wird nicht mehr eingelesen, sondern es erscheint folgende Fehlermeldung -

Listenindex überschreitet das Maximum(-1)

Wenn ich eine alte CSV und die neu exportierte CSV Datei vergleiche, fällt mir folgendes auf:
a) in der "alten CSV Datei" (erzeugt im Juli 2018) hatte ich nur 1 RIN -Spalte
b) in der neuen CSV Datei habe ich 9 RIN Spalten hintereinander und weiter hinten sogar eine RIN.10. (auffällig : In dieser Spalte weicht die RIN-Nr. von den Nummern der anderen Spalten ab, sofern eine RIN in dieser Spalte vorhanden ist)

die RIN der 1. Spalte ist identisch mit den .1 bis .9 RIN-Spalten,
-aber nur bei den "alten" Datensätzen vor Installation der neuen beta Version.

Alle "neuen" Datensätze die ich ab ca. 20.8.18 eingetragen habe, haben tw. nur 1 RIN-Nr. oder halt eben 2,3,4,5,6,7,8 identische RIN-Nr.
Wie oben geschrieben die Nummer in der Spalte RIN.10 ist abweichend, wenn vorhanden.

Ob diese Änderung (Fehler ? Bug ?) dafür verantwortlich ist, dass ich die CSV Datei nicht mehr einlesen kann ,weiss ich nicht ?

Übrigens : das zurück lesen funktioniert auch nicht mit Version 299a

Es wäre sehr schön, wenn das behoben werden kann.

Gruss, Rolf

Hallo,
ja , da gabs etwas Änderungen - versuchs mal mit der beta7. Und wie dur ja am Namen erkennst, ist es eine Beta-Version, also nur möglicherweise fehlerfrei und keinesfalls als "echte" Version zu verwenden.

Aber - das was du beschreibst, ist zwar möglich, aber weit jenseits der Empfehlungen, da übernimmt niemand Verantwortung. Sind doch sicher keine Änderungen, die nicht in AB selbst möglich sind?!?!

Hallo bjew,

das ist mir natürlich klar, dass es
1. eine beta Version ist und
2. Fehler drin sein können.

Verantwortung braucht auch niemand zu übernehmen, denn es ist ja nix passiert !!

War halt bisher nur sehr praktisch!

ok, werde es mal mit der Beta 7 versuchen.
Danke für den Hinweis
.
Aber trotzdem nochmal die Frage:
Warum plötzlich RIN.1 bis RIN.10 anstatt wie bisher RIN.1 und RIN.2
Darauf wollte ich eigentlich aufmerksam machen.

So, ich habe dasselbe wie oben jetzt mit beta 7 und Version 299a probiert.

Ergebnis : habe jetzt RIN.1 bis RIN.11 und dieselbe Fehlermeldung beim zurücklesen.

bjew schreibt:
Sind doch sicher keine Änderungen, die nicht in AB selbst möglich sind?!?!

Natürlich geht das alles relativ zeitaufwändig auch in AB.
Ist zwar schade, aber wie geschrieben, nix passiert.

Gruss
Rolf

Hallo Rolf,

ich finde, jetzt spätestens mit Version 3.0 sollte der Bearbeitungsweg AB > CSV > AB aufgegeben werden. Es gibt sicherlich noch ein paar Nutzungsmethoden, bei denen nichts Schlimmes passiert - aber das finde ich viel zu unsicher!

Daten aus der Ortsverwaltung gehen bekanntlich ebenso verloren beim Export in CSV wie die Daten zum Ersteller (also deine Kontaktdaten). Sowieso. Daten aus der Quellenverwaltung gehen m.E. nicht verloren, sondern werden in die Personendatensätze integriert. Die Familiendatensätze, also Angaben zur Partnerschaft, werden jeweils beiden Partnern in die Personendatensätze geschrieben - das ist soweit auch in Ordnung. Taufpaten und Trauzeugen gingen zuletzt im Test noch verloren, wenn sie nicht als Text, sondern als Person eingebunden waren. Ob sonst noch etwas verloren geht, habe ich nicht überblicken können, weil ich beim Anlegen einer Testdatei über 200 Spalten in eine CSV-Datei bekommen habe.

Klar, es geht auch weiterhin mit dieser Profi-Coder-Methode, um in Excel o.ä. Tabellenkalkulationen Operationen am offenen Brustkorb zu machen. Ich erlaube mir aber eine Warnung.

Frido

Allerdings ist diese Massenbearbeitung via CSV m.M. ein Alleinstellungsmerkmal von AB.

Bei den zu erwarteten komplexen Datenstrukturen wird es wohl schwierig.
GGf währe eine Art Teil-Export/Importfunktion ein Möglichkeit um zumindest einen Teil der Daten (nach Userauswahl) extern bearbeiten zu können.

Hallo,

ok, ich habe verstanden, dass ich bisher auf einem gefährlichen und schmalen Pfad gewandert mit meinem Handling der CSV Datei.
Aber... sniff... es hat so geschickt funktioniert.
Allerdings habe ich nur ganz wenige Rubriken in csv bearbeitet un zurückgelesen.
Geht nicht mehr, sei's drum.
Primär benutze ich die CSV Datei in Excel als "Suchdatei" um besser Querverbindungen von Person zu Person zu finden.
Auch neue Personen kann ich so besser/Komforetabler abgleichen
Dazu habe ich die Excel-Date so modifiziert, dass mir separat das Geburtsjahr angezeigt wird und danach kann ich die Datei super sortieren.
Ich muss vielleicht noch dazu sagen, dass ich an einer Familien-Datei arbeite ( von 1540 bis heute) und unheimlich viele Namensgleichheiten auftreten.
z. B. eine Anna Maria C. existiert über 400x und wenn ich nur Anna C. suche habe ich 1000 Treffer über die Jahre.
Für eine solche Übersicht war bzw. ist der Export in CSV/Excel echt sehr hilfreich und das bisherige zurücklesen halt ein Klasse Nebeneffekt.

Viele Grüsse vom Fuß der Schwäbischen Alb

Rolf

Hallo Rolf,
gibt vllt. noch einen Rauskommer. Es gibt Tools, die csv in Gedcom wandeln ..... was einen Tick mehr Sicherheit bringen würde .....

Hallo
ich hab mal noch eine Frage wegen Export der ahn.Datei in eine CSV Datei.
Ich bekomme jedesmal eine Fehlermeldung dass von der Ortsverwaltung und der Ortsverwaltung der Quellen bis zu 375 Sätze nicht einwandfrei oder nicht übernommen werden können.
Woran liegt das ?
Sind dafür evtl. Sonderzeichen wie ( ) / [ ] ? o.ä. die Verursacher ?
Oder hat das andere Gründe ?

Wäre dankbar für Hinweise, dann könnte ich evtl. meine Eingaben anpassen.

Oder ist das ein grundsätzliches Problem der Ortsverwaltung ?

PS. Es geht nicht um zurück lesen der Daten. Lediglich um korrekten Export.

LG Rolf

Hallo Rolf,

das CSV-Format bietet die Möglichkeit, strukturierte Daten in Tabellenform, also in Spalten und Zeilen gesetzt, zu speichern. Dabei wird in der ersten Zeile der Name der einzelnen Datenfelder definiert. Adressdaten beliebig vieler Personen z.B. lassen sich auf diese Weise gut darstellen. Aber es funktioniert eben nur mit konsistenten Daten: Alle Datensätze müssen dieselbe Struktur haben bzw. in eine endliche Zahl von Spalten aufgeteilt werden können.

Ahnenblatt speichert also lediglich Personendaten - pro Zeile eine Person, und alle anderen Daten müssen entweder in die Personendaten mit eingearbeitet werden (z.B. die Daten zu Partnerschaften) oder sie gehen beim Export verloren - das betrifft alle Daten in den neuen Zentralverwaltungen (Orte, Adressen, Quellen, Aufgaben)!

Anders gesagt: Du kannst nichts tun, um einen vollständigen Export deiner Daten im CSV-Format zu erreichen. Außer, du verzichtest auf all diese "Verwaltungen" und ihre zusätzlichen Felder.

Es wäre übrigens theoretisch durchaus möglich, beim CSV-Export einfach dafür zu sorgen, dass nicht nur eine CSV-Tabelle, sondern etwa 5 solche Tabellen erstellt werden - für jeden Datentyp eine. Dann müsste man nur noch dafür sorgen, dass der Zusammenhang zwischen diesen 5 versch. Datentypen nicht verloren geht. Aber das ist in Ahnenblatt nicht so - ich würde mal behaupten: einfach deswegen, weil diese "Verwaltungen" recht neu sind und die Möglichkeiten noch nicht ausentwickelt sind.

Die Meldung, von der du sprichst, ist also keine Fehlermeldung, sondern eine Warnung, dass man mit dem CSV-Export aktuell keine komplette Sicherung der eigenen Daten erreicht.

Frido

Hallo Frido,

Danke für die rasche Antwort.
Ich glaube, ich habe das jetzt einigermaßen verstanden, auch nachdem ich die Hilfedatei noch mal gelesen habe.
Dann kann ich zwar, wie bisher, mit einer CSV/Excel Tabelle als Suchhilfe arbeiten, aber eben nicht mehr.
Sicherungen erstelle ich; fast täglich nach grösseren Eingaben, sowieso in .ahn

LG von der Schwäbischen Alb
Rolf

*.ahn ist kurzfristig das ideale Backup-Format; jederzeit kann man eine solche Datei einlesen, hat sämtliche Inhalte gespeichert usw.

Für die langfristige Sicherung (also für Kinder und Enkel) wäre GEDCOM geeigneter - weil es eine Austausch-Plattform für andere Programme ist und sogar halbwegs im Nur-Text-Format lesbar ist.

CSV eignet sich aus den genannten Gründen nicht mehr.

Hallo Frido,

habe vergessen .ged zu erwähnen.
So ca. alle 4-8 Wochen erstelle ich auch eine gedcom Datei um diese bei GedBas einzuspielen und speichere diese jeweils mit Datum und Pers.Zahl separat ab.
Die CSV nutze ich nur noch um schnell zu einer Exceltabelle zu kommen die ich mir so aufbereitet habe, dass ich darin schnell Informationen abfragen, vergleichen und suchen kann.
Das hat mir schon oft geholfen Personen zu identifizieren, denn des öfteren sind die Schreibweisen unterschiedlich und AHNENBLATT findet dann die Zusammenhänge natürlich nicht.
Bei über 17000 Personen, die fast alle miteinander verknüpft sind musst Du sowas haben, sonst geht der Überblick leicht flöten. Ist so schon schwer genug.

LG Rolf.

Hallo rolf,
hast du schin mal versucht, die Datenbank unter einem neuen Namen zu speichern, dort dann die *.csv/*.ged einlesen. Könnte sein, dass die Orts-, Quellen und sonstigen Daten überleben.

Habs nicht probiert ()