Date: 2006/04/04 22:44:15
From: Herbert Penke <Penke1(a)gmx.de>
Hallovor mehr als geraumer Zeit wurde über einen GEDCOM Export 6.0 Format in XML diskutiert. GFAhnen hat damit experimentiert, ist aber serienmäßig nicht freigeschaltet, da der Standart endgültig noch nicht abgesegnet
Wie ist der Stand bei anderen Programmen und wer arbeitet damit.Die Archive wie das Staatsarchiv Detmold möchten für Ihre Datenbank Verkartungen eventuell auch in XML haben. Entspricht das von den Archiven geforderte XML den Vorgaben des Vereines Computergenealogie? MfG Herbert Penke
Date: 2006/04/04 23:16:25
From: Stefan Mettenbrink <S.Metti(a)gmx.de>
Herbert Penke wrote:
Wie ist der Stand bei anderen Programmen und wer arbeitet damit.
Hat sich nicht durchgesetzt. Keiner fragt danach und es bietet dem Anwender keinen Vorteil. Vor allem die fehlende Verabschiedung als gültigen Standard hindert die Anbieter es zu implementieren. Es besteht die Gefahr, sich Arbeit zu machen, die man nachher in die Tonne kloppen kann. Das alles ohne Zusatznutzen für das Programm. Wenn Du jetzt anfängst Vorteile von XML aufzuzählen, beschränk Dich auf Vorteile für den Programmanbieter. Die bauen eine Funktion nur ein, wenn sie einen Monetären Vorteil bieten, weil Anwender dafür zahlen. Gedcomexport ist ein Pflichtfunkton. Mit Gedcom 5.5 ist dem genüge getan und bereits vorhanden. Also welchen Vorteil hätte 6.0? MfG, Metti.
Date: 2006/04/05 07:58:36
From: Herbert Penke <Penke1(a)gmx.de>
Hallo welchen Vorteil XML bietet weiß ich auch nicht. Das Staatsarchiv Detmold arbeitet wie alle Archive mit einem Datenbankprogramm Vera, dieses kann unter anderen laut Beschreibung mit einem Import von XML-Dateien arbeiten. Man weis im Archiv zwar nicht genau, wie das XML-Format aussehen muß, aber man wünscht es. Zu XML-Gedcom 6.0: Aus meiner Sicht gehört es zu den unvollendeten Projekten von Computergenealogie: Schnell was anfangen, keine genauen Programmrichtlinien erstellen und es dann stillschweigend beerdigen MfG Herbert Penke > > Wenn Du jetzt anfängst Vorteile von XML aufzuzählen, beschränk > Dich auf Vorteile für den Programmanbieter. Die bauen eine Funktion > nur ein, wenn sie einen Monetären Vorteil bieten, weil Anwender > dafür zahlen. Gedcomexport ist ein Pflichtfunkton. Mit Gedcom 5.5 ist > dem genüge getan und bereits vorhanden. Also welchen Vorteil hätte > 6.0? -- E-Mails und Internet immer und überall! 1&1 PocketWeb, perfekt mit GMX: http://www.gmx.net/de/go/pocketweb
Date: 2006/04/05 09:04:29
From: Heinrich Schiffers <heinrich.schiffers(a)web.de>
Herbert Penke schrieb am 05.04.2006: >Hallo >welchen Vorteil XML bietet weiß ich auch nicht. >Das Staatsarchiv Detmold arbeitet wie alle Archive mit einem >Datenbankprogramm Vera, dieses kann unter anderen laut Beschreibung mit >einem Import von XML-Dateien arbeiten. >Man weis im Archiv zwar nicht genau, wie das XML-Format aussehen muß, aber >man wünscht es. Was ist VERA ? Das kann man hier nachlesen: http://www.spiconsultsystems.de/index.php?id=2 Gruß Heinrich Schiffers
Date: 2006/04/05 09:24:33
From: Norbert.Roclawski <norbert.roclawski(a)superkabel.de>
Hallo, >Herbert Penke schrieb am 05.04.2006: >>Hallo >>welchen Vorteil XML bietet weiß ich auch nicht. >>Das Staatsarchiv Detmold arbeitet wie alle Archive mit einem >>Datenbankprogramm Vera, dieses kann unter anderen laut Beschreibung mit >>einem Import von XML-Dateien arbeiten. >>Man weis im Archiv zwar nicht genau, wie das XML-Format aussehen muß, aber >>man wünscht es. >>Aus meiner Sicht gehört es zu den unvollendeten Projekten von >>Computergenealogie: >>Schnell was anfangen, keine genauen Programmrichtlinien erstellen und es >>dann stillschweigend beerdigen >Heinrich Schiffers schrieb am 5.4.2006: >Was ist VERA ? >Das kann man hier nachlesen: >http://www.spiconsultsystems.de/index.php?id=2 Nein, das scheint nicht das gemeinte Projekt zu sein. Das Projekt Vera, in der Nordrhein Westfälischen Archiveraltung, dass ein Datenbanksystem benutzt, scheint in diesem Artikel erwähnt zu sein: http://www.vsa-aas.org/fileadmin/user_upload/texte/ag_form/at_2004/at_2004_b rubach.pdf Bitte bis Abschnitt 3. Zukünftige Entwicklungen, vorblättern. Warum sollten viele Ahnenforscher in Ihren Genealogie Programmen zu diesem Einzel-System, dass schon in wenigen Jahren wieder überholt ist, eine kompatible Schnittstelle besitzen? Gruß Norbert Roclawski
Date: 2006/04/05 10:40:00
From: Markus Christ <m.christ(a)christm.ch>
Guten Tag GEDCOM GEDCOM wurde von den "Mormonen" (Heiligen der Letzten Tage) enwickelt. Wieso? Sie haben sich zum Ziel gesetzt, möglichst viele genealogischen Daten zu sammeln. Dies konnten Sie nicht alleine erreichen, haben den GEDCOM-Format erstellt, und sind somit in der Lage, Daten aus den vielen Programmen in einer (Ihrer) Datenbank zu sammeln. Obwohl die selbe Organisation den 6er-Format kreiert hat, hat sie diesen nicht verabschiedet. Wieso, es bringt für die "Datensammlung" keinen Vorteil, ob diese in GEDCOM 5.5 oder 6 zugesandt wird. Unterdessen hat GEDCOM auch für den User viele bekannte Vorteile und auch neue Probleme gebracht :-) XML bietet für den Anwender direkt keinen Vorteil, aber für den Programmierer und der Kompatibilität der Sprache - sowie die totale Trennung der Struktur, des Inhaltes und Formates, sollte es eine poblemlosere Übernahme auch in andere Datenbanken ermöglichen. http://www.internet-kompetenz.ch/xml/einfuehrung/ Trotzdem könnte es einen Vorteil bringen, denn durch die Voraussetzungen des XML wäret eine verbesserter (evtl. problemloserer) Datenautausch für den Endanwender möglich... Für Schnittstellen zu anderen Datenbanken in archiven wäre es ein "Segen" für den Programmierer.... Herzliche Grüsse Markus > Hallo > welchen Vorteil XML bietet weiß ich auch nicht. > Das Staatsarchiv Detmold arbeitet wie alle Archive mit einem > Datenbankprogramm Vera, dieses kann unter anderen laut Beschreibung mit > einem Import von XML-Dateien arbeiten. > Man weis im Archiv zwar nicht genau, wie das XML-Format aussehen muß, aber > man wünscht es. > Zu XML-Gedcom 6.0: > Aus meiner Sicht gehört es zu den unvollendeten Projekten von > Computergenealogie: > Schnell was anfangen, keine genauen Programmrichtlinien erstellen und es > dann stillschweigend beerdigen > MfG Herbert Penke >> >> Wenn Du jetzt anfängst Vorteile von XML aufzuzählen, beschränk >> Dich auf Vorteile für den Programmanbieter. Die bauen eine Funktion >> nur ein, wenn sie einen Monetären Vorteil bieten, weil Anwender >> dafür zahlen. Gedcomexport ist ein Pflichtfunkton. Mit Gedcom 5.5 ist >> dem genüge getan und bereits vorhanden. Also welchen Vorteil hätte >> 6.0? > > -- > E-Mails und Internet immer und überall! > 1&1 PocketWeb, perfekt mit GMX: http://www.gmx.net/de/go/pocketweb > _____________________________________________ > An-, Abmelden bzw. persoenliche Einstellungen aendern > http://list.genealogy.net/mailman/listinfo/genealogie-programme >
Date: 2006/04/05 17:07:20
From: Stefan Mettenbrink <S.Metti(a)gmx.de>
Herbert Penke wrote:
Das Staatsarchiv Detmold arbeitet wie alle Archive mit einem Datenbankprogramm Vera, dieses kann unter anderen laut Beschreibung mit einem Import von XML-Dateien arbeiten.
Einen Export nach XML kann man sicher bekommen. Ob der nach Gedcom 6.0 Definition sein muss, solltest Du dann aber vorher klären.
Man weis im Archiv zwar nicht genau, wie das XML-Format aussehen muß, aber man wünscht es.
Wenn Du nicht weißt, in welchen Hafen Du segelst, ist kein Wind der richtige. Klär doch erst was Du benötigst, bevor Du Gedcom 6.0 wünscht. Wenn Du weißt, was Du benötigst, kann man Dir sicher helfen.
Zu XML-Gedcom 6.0: Aus meiner Sicht gehört es zu den unvollendeten Projekten von Computergenealogie:
GanzDeiner Meinung. :-( MfG, Metti.
Date: 2006/04/05 17:07:21
From: Stefan Mettenbrink <S.Metti(a)gmx.de>
Markus Christ wrote:
XML bietet für den Anwender direkt keinen Vorteil, aber für den Programmierer und der Kompatibilität der Sprache - sowie die totale Trennung der Struktur, des Inhaltes und Formates, sollte es eine poblemlosere Übernahme auch in andere Datenbanken ermöglichen. http://www.internet-kompetenz.ch/xml/einfuehrung/ Trotzdem könnte es einen Vorteil bringen, denn durch die Voraussetzungen des XML wäret eine verbesserter (evtl. problemloserer) Datenautausch für den Endanwender möglich... Für Schnittstellen zu anderen Datenbanken in archiven wäre es ein "Segen" für den Programmierer....
Ich bin einer der erwähnten Programmierer und habe die von Dir erwähnten Vorteile bisher icht erkannt. MfG, Metti.
Date: 2006/04/05 17:33:24
From: Herbert Penke <Penke1(a)gmx.de>
Hallo besten Dankaber wie schon gesagt GFAhnen hat die Schittstelle und ich habe diese getestet, der Wunsch ist schon erfüllt
Jetzt muß halt das Archiv damit zurecht kommen. MfG Herbert Penke Herbert Penke wrote:
Man weis im Archiv zwar nicht genau, wie das XML-Format aussehen muß, aber man wünscht es.
Wenn Du nicht weißt, in welchen Hafen Du segelst, ist kein Wind der richtige. Klär doch erst was Du benötigst, bevor Du Gedcom 6.0 wünscht.
Date: 2006/04/05 18:31:23
From: Stefan Mettenbrink <S.Metti(a)gmx.de>
Herbert Penke wrote:
aber wie schon gesagt GFAhnen hat die Schittstelle und ich habe diese getestet, der Wunsch ist schon erfüllt Jetzt muß halt das Archiv damit zurecht kommen.
Da ist halt die Frage, in wie weit Du den Import des Archives an Gedcom 6.0 anpassen kannst (sofern Du es must). MfG, Metti.
Date: 2006/04/07 21:32:23
From: Heinz Köhler <hkoehler(a)sampo.de>
Hallo,wer kennt ein Genealogieprogramm, welches den Forscher bei der Familienzusammenführung maßgeblich unterstützt?
Beispiel:Das Programm erkennt die Personen in der Genealogie, welche keine Eltern haben. Anschließend macht das Programm Vorschläge von möglichen Eltern zum Beispiel mit Soundex des Nachnamens o.ä. Auswahlmöglichkeiten. Diese Vorschläge können dann anschließend gut als Eltern (Partner, usw.) verknüpft werden.
Das Programm sollte, wenn möglich Gedcom-Daten verwenden können.Für eine Verkartung, oder auch sonst wäre das eine feine Sache, wenn es so etwas geben würde.
Danke für die Unterstützung und herzliche Forschergrüße Heinz (Köhler)
Date: 2006/04/07 23:01:15
From: Claudia <Claudia(a)j-t.de>
Hallo Herr Köhler, da hätte ich auch noch einen Wunsch: ----------Wenn das Programm gleich die Daten aus der Telefon-CD mitverarbeiten würde, wäre eine Verkartung von z.B. Deutschland wesentlich vereinfacht! Vielleicht wäre eine Programmergänzung möglich, die gleich die Adressen mit den Telefonnummern auswerfen würde, damit dann ein großes Familientreffen sehr einfach zu planen wäre. So stelle ich mir vor, daß zu Pfingsten ein Treffen aller "Müller´s und Meier`s auf Anhieb zu organisieren wäre. Idealer Weise sollte dann noch eine Funktion implementiert werden, die auch sofort eine passende Räumlichkeit benennen würde, um die zu erwartenden Menschen unterzubringen. ( Messe Hannover oder so.... damit allen ein Licht aufgehe)
Grenzenlose Grüße Claudia Janßen-Timmen(die morgen schon in den Alpen keine Schläge aus der Liste zu befürchten hat)
Heinz Köhler schrieb:
Hallo,wer kennt ein Genealogieprogramm, welches den Forscher bei der Familienzusammenführung maßgeblich unterstützt?Beispiel:Das Programm erkennt die Personen in der Genealogie, welche keine Eltern haben. Anschließend macht das Programm Vorschläge von möglichen Eltern zum Beispiel mit Soundex des Nachnamens o.ä. Auswahlmöglichkeiten. Diese Vorschläge können dann anschließend gut als Eltern (Partner, usw.) verknüpft werden.Das Programm sollte, wenn möglich Gedcom-Daten verwenden können.Für eine Verkartung, oder auch sonst wäre das eine feine Sache, wenn es so etwas geben würde.Danke für die Unterstützung und herzliche Forschergrüße Heinz (Köhler) _____________________________________________ An-, Abmelden bzw. persoenliche Einstellungen aendern http://list.genealogy.net/mailman/listinfo/genealogie-programme
Date: 2006/04/08 07:18:09
From: Stefan Mettenbrink <S.Metti(a)gmx.de>
Heinz Köhler wrote:
Das Programm erkennt die Personen in der Genealogie, welche keine Eltern haben. Anschließend macht das Programm Vorschläge von möglichen Eltern zum Beispiel mit Soundex des Nachnamens o.ä. Auswahlmöglichkeiten. Diese Vorschläge können dann anschließend gut als Eltern (Partner, usw.) verknüpft werden.
Ich kenne ein Programm, das die Grundfunktion (Erkennung von möglichen Eltern anhand von Soundex- und Geburts-/Sterbedaten) enthält. Fehlen würde lediglich eine Funktion, mit der man gezielt eine Suche nach Personen mit fehlendem Elternteil anstößt, um bei denen Vorschläge zu machen. MfG, Metti.
Date: 2006/04/08 10:12:30
From: Gerhard <ggsch1147(a)gmx.net>
Hallo Heinz, wieder mal beim Provozieren von Programmautoren? [..] > wer kennt ein Genealogieprogramm, welches den Forscher bei der > Familienzusammenführung maßgeblich unterstützt? > > Beispiel: > Das Programm erkennt die Personen in der Genealogie, welche > keine Eltern haben. Gegenfrage: Gibt es ein Genealogieprogramm, welches KEINE (vorhandenen) Eltern anzeigt? > Anschließend macht das Programm Vorschläge von möglichen Eltern zum > Beispiel mit Soundex des Nachnamens o.ä. Auswahlmöglichkeiten. Vorschläge für den Vater sind ja sicher noch machbar! Es gibt Programme, dies dies so realisiert haben. > Diese Vorschläge können dann anschließend gut als Eltern > (Partner, usw.) > verknüpft werden. Wie stellen Sie sich aber die Vorschläge für Mütter und Ehefrauen vor, die ja in der Regel anderslautende Namen tragen. Sollte ein Programm auch noch hellsehen können? Könntest Du hier selbst einmal realistische Vorschläge unterbreiten! Vielleicht würden diese dann von den hier mitlesenden Programmautoren realisiert. > Das Programm sollte, wenn möglich Gedcom-Daten verwenden können. Gegenfrage: Gibt es noch Genealogieprogramme, die KEINEN GEDCOM-Import besitzen. > Für eine Verkartung, oder auch sonst wäre das eine feine > Sache, wenn es so etwas geben würde. > > Danke für die Unterstützung und herzliche Forschergrüße > > Heinz (Köhler) mit freundlichen Grüßen Gerhard
Date: 2006/04/08 11:41:50
From: Heinz Köhler <hkoehler(a)sampo.de>
Hallo Gerhard, warum sollte ich jemanden ärgern? --> will mich jemand ärgern?Achtung, das Thema ist nicht ganz einfach zu verstehen! Einfach die Mail löschen, wenn es zu kompliziert erscheint :-[
Habe ein Problem, welches ich mal wieder lösen möchte. Deshalb die Frage um Unterstützung an alle und nicht immer nur Unterstützung von meiner Seite! :-(
Das Forschungsgebiet beinhaltet einige tausende von Datensätzen.Viele der Datensätze haben nur eine Elternangabe (Beispiel: Karl Mustermann, geb. 01.01.1800, gest. 01.01.01860; Vater: Johann Mustermann, geschätztes Geburtsdatum 1770, Mutter: Barbara, geschätztes Geburtsdatum 1770). Hier ist der Johann mit seiner Frau Barbara in der Spitzenahnposition.
Jetzt will ich einfach nur Unterstützung bei der Familienzusammenführung.Es soll Verkartungsprogramme geben (VKwin --> soll keinen Gedcomimport haben!, .....).
Anmerkung: ich kenne persönlich keines. Deshalb die Frage an die Runde. OK?Gerhard, welches Programm kann den Vater vorschlagen? (war doch meine Frage) :-\
************************* Grundlage:In meiner Genealogie haben alle Personen mindestens ein geschätztes Geburtsdatum.
Lösungsansatz:(gehe nur mal von den Familienzusammenführung einer Ahnenlinie aus. Die Genealogie umfasst aber wesentlich mehr Personen. Faktor 10!):
Die Kinder der Spitzenahnen haben (meistens) ein qualifiziertes Geburtsdatum (Karl Mustermann, 01.01.1800). Der Vater Johann mit dem geschätzten Geburtstag 1770 bildet die Basis zur Suche. Jetzt soll das Programm die Soundex-Mustermänner im Geburtsbereich von 1750 bis 1790 in einem Auswahlfenster mit den kompletten Daten (Hausvater: Geburt, Tod, Heirat; Hausmutter: Geburt, Tod; Kinder mit Geburt und Tod) in einer Zeile darstellen (Die Kinder sollten nach dem Geburtsjahr sortiert sein) bereit stellen.
Danach will ich nur noch die Eltern von Karl Mustermann (01.01.1800) anselektieren und mit ihm verknüpfen/verschmelzen.
Wäre das keine vorstellbare Unterstützung in einem Genealogieprogramm? Ich könnte es mir mal wieder sehr gut vorstellen *grins*Vielleicht fühlen sich einige bei der aufgestellten Visionen etwas überfordert.
Das stellt für mich ja auch kein Problem dar. Mit der Zeit werden die Ansprüche und Vorstellungen immer größer *lächel* Ist die Erklärung jetzt verständlicher? O:-)(werde das etwas etwas kompliziertes Thema evt. in Kürze wiederum in Genwiki einstellen. ---> wie den Duplikats-Differenz-Vergleich) :-\
Das Thema ist auch für Denjenigen interessant, der viele Daten über Batchnummern aus dem Internet herunter downloadet.
Falls jemand weitergehende Fragen dazu hat, kann er sich gerne mit mir direkt in Verbindung setzen (auch telefonisch).
Herzliche Grüße, ein etwas verwunderter Heinz (Köhler) ---------------------------------------- Hallo Heinz,wieder mal beim Provozieren von Programmautoren?
[..]
wer kennt ein Genealogieprogramm, welches den Forscher bei der Familienzusammenführung maßgeblich unterstützt?Beispiel:Das Programm erkennt die Personen in der Genealogie, welche keine Eltern haben.
Gegenfrage: Gibt es ein Genealogieprogramm, welches KEINE (vorhandenen) Eltern anzeigt?
Anschließend macht das Programm Vorschläge von möglichen Eltern zum Beispiel mit Soundex des Nachnamens o.ä. Auswahlmöglichkeiten.
Vorschläge für den Vater sind ja sicher noch machbar! Es gibt Programme, dies dies so realisiert haben.
Diese Vorschläge können dann anschließend gut als Eltern (Partner, usw.) verknüpft werden.
Wie stellen Sie sich aber die Vorschläge für Mütter und Ehefrauen vor, die ja in der Regel anderslautende Namentragen. Sollte ein Programm auch noch hellsehen können? Könntest Du hier selbst einmal realistische Vorschläge unterbreiten! Vielleicht würden diese dann von den hier
mitlesenden Programmautoren realisiert.
Das Programm sollte, wenn möglich Gedcom-Daten verwenden können.
Gegenfrage: Gibt es noch Genealogieprogramme, die KEINEN GEDCOM-Import besitzen.
Für eine Verkartung, oder auch sonst wäre das eine feine Sache, wenn es so etwas geben würde.Danke für die Unterstützung und herzliche Forschergrüße Heinz (Köhler)
mit freundlichen Grüßen Gerhard
Date: 2006/04/08 11:54:57
From: Stefan Mettenbrink <S.Metti(a)gmx.de>
Gerhard wrote:
Wie stellen Sie sich aber die Vorschläge für Mütter und Ehefrauen vor, die ja in der Regel anderslautende Namen tragen.
Die vorgeschlagenen Personen sin weiblich, im gebärfähigem Alter zum Zeitpunkt der Geburt einer Person.
Gegenfrage: Gibt es noch Genealogieprogramme, die KEINEN GEDCOM-Import besitzen.
Ja. MfG, Metti.
Date: 2006/04/08 13:05:39
From: Gerhard <ggsch1147(a)gmx.net>
Hallo Heinz, aus Mettis Mail interpretiere ich, dass er Deine Vorschläge locker in seinem Programm realisieren könnte! Beknie Ihn doch einfach so lange, bis er es tut. Ich habe Ihn schon gebeten, mir auch Bescheid zu geben, wenn er Deine Vorschläge realisiert hat. Mit freundlichen Grüßen Gerhard > -----Ursprüngliche Nachricht----- > Von: genealogie-programme-bounces(a)genealogy.net > [mailto:genealogie-programme-bounces(a)genealogy.net] Im > Auftrag von Heinz Köhler > Gesendet: Samstag, 8. April 2006 11:41 > An: ggsch1147(a)gmx.net; kb-verkartung(a)genealogy.net; > genealogie-programme(a)genealogy.net; compgend-l(a)genealogy.net > Betreff: [Gen-Programme] Re: Suche Genealogieprogramm zur > Unterstützung bei der Familienzusammenführung > > Hallo Gerhard, > > warum sollte ich jemanden ärgern? --> will mich jemand ärgern? [..]
Date: 2006/04/08 14:02:45
From: Stefan Mettenbrink <S.Metti(a)gmx.de>
Gerhard wrote:
aus Mettis Mail interpretiere ich, dass er Deine Vorschläge locker in seinem Programm realisieren könnte!
Ich hatte schon Kontakt mit Heinz und habe Teile seiner Probleme in Funktionen meines Programms umgesetzt. Das was er hier sucht ist nicht mit ein paar Worten erklärt. Die Umsetzung dessen wird sicher ebenfalls nicht einfach. Ob alles, so wie er es gern hätte umsetzbar ist, kann ich auch nicht sagen. Ist aber auch egal. Programme sind Werkzeuge. Sie sollen bei der Arbeit helfen. Heinz such ein Werkzeug, das ihm hilft. Scheinbar gibt es das noch nicht. Was liegt also näher, zu beschreiben, was er sucht und nach einer entsprechenden Umsetzung zu fragen?
Ich habe Ihn schon gebeten, mir auch Bescheid zu geben, wenn er Deine Vorschläge realisiert hat.
Du kennst mein Programm? MfG, Metti.
Date: 2006/04/09 07:19:45
From: w.turski <w.turski(a)T-Online.de>
Liebe Listenmitglieder, in vorliegendem Fall hat ein Mann aus seiner ersten Ehe Nachkommen,wird Witwer, und zeugt ein uneheliches Kind. Er heiratet die Mutter dieses Kindes aber nicht,sondern eine andere Frau. Mit dieser seiner 2. Frau zeugt er wiederum Nachkommen. Für mich vorrangig sind die Vorfahren des unehelichen Kindes. Inwieweit muss ich die mütterlichen Vorfahren der ehelichen Kinder mitberücksichtigen und erforschen. Mit freundlichem Gruß Waltraud (Turski)
Date: 2006/04/09 08:37:02
From: Stefan Mettenbrink <S.Metti(a)gmx.de>
Waltraud wrote:
Inwieweit muss ich die mütterlichen Vorfahren der ehelichen Kinder mitberücksichtigen und erforschen.
Die Genealogie ist Dein Hobby, Du entscheidest. Du wirst feststellen, dass die Suche nie endet. Immer hat jemand noch Vorfahren, Kinder oder Partner die Du noch nicht gesucht/gefunden hast. Die einfachste Variante wäre, nur die direkte Linie zu erforschen. Also immer nur die bekannte Person und dessen Eltern. Da bist Du recht schnell am Ende der Möglichkeiten. (7 Generationen=127 Personen, dafür gibt es schöne Schmucktafeln) MfG, Metti.
Date: 2006/04/14 21:56:03
From: Heinz Köhler <hkoehler(a)sampo.de>
Hallo Forscherfreunde,so wie es den Anschein hat, gibt es nichts passendes auf dem Genealogie-Markt.
Also habe ich meine bescheidenen Excel-Kenntnisse wieder mal eingesetzt und den Rechner etwas arbeiten lassen.
Der Rechner soll uns doch bei der Arbeit unterstützen! *lächel* Zielvorgabe: Für die vorletzte Ahnenperson weitere mögliche Eltern finden. Basisvorgaben: Suchpersonendatensätze: ca. 25.000 vorletzte Ahnenpersonenanzahl: 415 Spitzenahnenanzahl: 944Die Berechnung und Umsetzung war in minutenschnelle bei aktiviertem Bildschirm erledigt.
Das händische Überprüfen dauerte am längsten. Es wurden 11 Paare gefunden, die noch näher betrachtet werden. :-\
Gesucht wurde nach möglichen Ahnen wird über den Soundex des Nachnamens.Der Suchbereich ist einstellbar (im 2. Suchlauf: Elternmingrenze: -15 Jahre, Elternmaxgrenze: - 45 Jahre)
Da ich sehr viele "CA"-Datums habe, wurden diese im 2, Suchlauf automatisch gelöscht.
Mit dieser einfachen Sache läßt sich natürlich weiteres erschließen. *frechgrins*
Im Augenblick schließe ich jegliche Diskussion aus, da auch ich Ostern habe.
Werde das Thema in den nächsten Wochen ins Genwiki einstellen. Diskriminierende Diskussionen sollte jeder mit sich selbst halten. Bitte nur sachliche und weiterführende Diskussionen Herzlichen Dank und noch ein schönes Osterfest. Herzliche Ostergrüße aus Nufringen Heinz (Köhler) :-)
Date: 2006/04/14 22:54:04
From: Stefan Mettenbrink <S.Metti(a)gmx.de>
Heinz Köhler wrote:
Mit dieser einfachen Sache läßt sich natürlich weiteres erschließen.
Viel Erfolg. MfG, Metti.
Date: 2006/04/25 10:13:30
From: Ahnen-Pool <info(a)ahnen-pool.info>
Liebe Listenteilnehmer, bereits vor Jahren meldete ich mich schon einmal mit dem obigen Problem der nicht möglichen Optimierung von Daten aus GenProfi 3.4. Wenn ich auch heute nicht so recht glauben kann, dass Sie mir tatsächlich helfen können, ist es sicher gut, wenn man sich zumindest über die Probleme austauschen kann. Also, (auch für Nicht GenProfi-Nutzer) mein Ahnen-Pool arbeitet noch mit dem DOS-basierten GenProfi Version 3.4 von Heiko Thimm unter WindowsXP. Infolge des hohen konventionellen Speicherbedarfs sind einige Anpassungen in der autoexec.nt und in der config.nt für Speicherverwaltung und bei der Anzahl der Files erforderlich. Abgesehen von Meldungen bei der kontinuierlichen Dateneingabe wie maximale Schachtelung erreicht, die ein Schließen und Neuaufruf des Programms erforderlich machen, gab es sonst nie Probleme. Dagegen teilen viele Anwender von GenProfi und insbesondere Außenstehende die Auffassung, dass die DOS-Technologie, auf der GenProfi 3.4 basiert, nicht für über 195.000 Datensätze -- und schon gar nicht für das wiederholte Speichern und Löschen von Datensätzen respektive einer potentiell unendlichen Verschachtelungstiefe auf Datei-Basis ausgelegt ist. Sie akzeptieren aber gerne, dass GenProfi 3.4 Funktionalitäten besitzt, an die kein modernes, windowsbasiertes Ahnenforschungsprogramm heranreicht. Aber "physikalisch" sind eine Single-Task-Plattform und eine 16-Bit-Datenbank für komplexen Anforderungen ausgereizt; sie einfach am Ende. Sie vertreten die Meinung, dass es nur Niemand wagt, es uns gegenüber das so direkt auszudrücken: Aber stunden-, tagelange Wartezeiten -- egal für welche Datenbank-Operation (Konvertieren, Exportieren, Kopieren ...) -- sind bei einem Datenbestand von "bloß" 195.000 Datensätzen völlig inakzeptabel! Und so stelle ich fest, dass bis heute noch kein Programm erschienen ist, das von der Anwendung her (abgesehen von optisch nett anmutenden Schnick-Schnack) eine wirkliche Konkurrenz sein könnte. Und obwohl ich mit meinen 70 Jahren immer noch erfreulich beweglich bin, möchte ich mir keine neue Lernphase mit wechselhaftem Ausgang auferlegen. Ich war eigentlich immer sehr zufrieden mit dem Programm, wenngleich es einer jahrelangen Übung bedurfte, bis man viele Facetten des Programms so beherrscht, das man damit effektiv arbeiten kann. Es verfügt über zahlreiche Register, die sich automatisch anlegen oder die man auch von Hand aufbauen kann, die die Dateneingabe wesentlich vereinfachen. Es arbeitet meines Wissens nach dem Prinzip der Vereinzelung, das dafür sorgt, dass alle Begriffe nur ein einziges Mal gespeichert werden und nur mit entsprechenden Zeigern verbunden werden. Es arbeitet meines Wissens nach auf einem dBase orientierten amerikanischen Programm, dessen Hersteller in Insolvenz ging und infolgedessen keinen Support mehr bietet (wahrscheinlich XPro). Es ist mandantenfähig, indem es beliebig viele Forschungsbereiche bietet. Es erzeugt Dateien für Abkürzungen, Daten, Familien, Orte, Personen, Register und Tabellen1 und 2 jeweils mit den Suffixen DBF und CDX. Für die Daten, Ort und Register werden zusätzlich noch eine Datei mit dem Suffix DBV gebildet. Es verwendet eine xBase-Struktur mit einer proprietärer Memo-Feld- Erweiterung, deren Datenverbindungen bisher auf der Zahlenbasis 233 berechnet werden. Zur Datenpflege bietet das Programm nachstehende Optionen: · Indexdateien neu erstellen · Optimierung des Datenbestandes · Aktualisierung Kennzeichendatenbank mit Standardwerten · Umsetzung des Datenbestandes auf einen anderen Forschungsbereich · Kopieren des Datenbestandes auf einen anderen Forschungsbereich · Kopieren Register und Kennzeichen auf einen anderen Forschungsbereich sowie zahlreiche Optionen zur wahlweisen Schlüsselerzeugung, zur Plausibilitätsprüfung, zur chronologischen Sortierung und zur Alias-Verwendung. Die erste Option ist dafür, wenn gelegentliche Abstürze einen Indexneuaufbau erforderlich machen. Die Option Optimierung ist gelegentlich erforderlich, um die Datenbank aufzuräumen (gelöschte Datensätze zu entfernen und die zahlreichen Sachgebiete aufzuräumen (Vereinzelung). Und da diese Optimierung bei einem großen Datenbestand bis zu über einer Stunde Rechnerzeit beansprucht, wurde sie neben der eigentlichen Datensicherung nicht allzu regelmäßig durchgeführt. Und eines Tages ließ sich die Optimierung überhaupt nicht mehr durchführen, weil die dazu erforderliche Routine nicht mehr anlief. Stattdessen erschien eine Fehlermeldung: Speicherplatz reicht für Optimierung nicht aus! Abbruch!. Wie sich in zahlreichen Versuchen meinerseits herausstellte, war das eine absolute Falschmeldung und ich hatte den Verdacht, dass die erforderliche Routine die tatsächliche Größe der inzwischen mächtig gewachsenen Festplatten nicht richtig erkennt. Eine Rückfrage beim Entwickler Heiko Thimm, dem diese Meldungen nicht unbekannt waren, vertröstete auf eine neue Version von GenProfi auf einer anderen Datenbankbasis. Da diese Entwicklung noch im Gange war und sich anfänglich allerlei Kinderkrankheiten zeigten, entschloss ich mich noch nicht auf eine Umstellung auf die neue Version und arbeitete auf eigene Gefahr weiter. Inzwischen wurde die neue Version frei gegeben; aber ich konnte auch mit dieser Version nicht arbeiten, weil zuvor eine Datenkonvertierung erforderlich ist, deren Routine ebenfalls nicht anläuft oder zu Ende läuft und die gleiche Fehlermeldung: Speicherplatz reicht für Optimierung nicht aus! Abbruch! liefert. Wiederholte Rückfragen beim Entwickler bestätigten mir, dass an diesem Problem gearbeitet wird. Ich will in diesem Zusammenhang nichts unterstellen, aber Herr Thimm scheint mir arbeitsmäßig hoffnungslos überfordert zu sein. Hinweise unter seinem Namen im Internet zeigen mir, dass er auch erhebliche wissenschaftliche Verpflichtungen wahrzunehmen hat. Beim Umsetzen dieser Dateien z. B. auf meinen Laptop war es wegen der immensen Größe einzelner dieser Dateien nicht mehr möglich, diese mit einem UBS-Stift umzusetzen. Also versuchte ich, diese zu komprimieren. Abgesehen von dem erheblichen Zeitaufwand für das Komprimieren zeigte es sich auch, das manche komprimierte Dateien nicht wieder entpackt werden konnten. Da dieses Verhalten nur die dat__ac.dbv (AC steht für Forschungsbereich AC) aufweist, glaube ich nunmehr, dass diese korrupt ist. Sie besitzt im Gegensatz zu der neu erzeugten Datei von 11.871 MB die gigantische Größe von 1.064.678 MB, ist also fast zehnmal so groß. Vielleicht ist der Header kaputt oder diese Datei hat durch einen Crash eine mehrfache Spiegelung erfahren?! Mit Excel ist diese Datei provisorisch einsehbar, obwohl Excel eindeutig meldet, dass es das Format nicht kennt. Dabei zeigte die Anzahl der Datensätze jedoch die richtige Größe. Obwohl ich beruflich meine Routinen zur Projektverwaltung in der Arzneimittelentwicklung längere Zeit in dBase/Clipper schrieb, habe ich jedoch gewisse Hemmungen, mich an einer relationalen Datenbank zu versuchen, für die mir nicht heute nicht einmal die notwendigen Programme zur Verfügung stehen. Überlegungen in dieser Zeit auf ein anderes Ahnen-Programm umzusteigen, scheiterten meist an der Feststellung, dass viele der sehr umfangreichen Möglichkeiten von GenProfi nicht von diesen Programmen übernommen werden können. Insbesondere kommen die gesamten Daten, die in GenProfi eingebracht wurden, mit den Export-Routinen von GenProfi nur teilweise wieder heraus. In diesem Zusammenhang interessierte mich auch MySQL. Aber ich wollte meine Dateien doch nicht völlig frei ins Internet stellen, und auch eine Umstellung auf ein neues Programm bedarf doch einer erheblichen neuen Einarbeitung. Und schließlich passierte das, was ja unweigerlich irgendwann passieren musste. Nach einem Aufruf des Programms zeigte es nur einen völlig minimierten Datenbestand an, der nach einer nicht nachvollziehbaren Explosion übrig geblieben war. Ein Rückgriff auf eine Datensicherung, die leider schon eine Woche alt war (eine wie meist sehr arbeitsreiche Woche) konnte in etwa den alten Zustand wieder herstellen, aber die ursprüngliche Gefahr mit der fehlenden Optimierungsmöglichkeit blieb unverändert. Aus diesem Grunde bemühte ich mich, aus diesem Datenbestand eine völlig neue Datenbank in einem anderen Forschungsbereich aufzubauen. Nach zahlreichen meist über 10-stündigen Versuchen mit Kopieren usw. liegt dann erst ein Ergebnis vor, das meist unbefriedigend ist, weil es fehlerbehaftet oder unvollständig ist. Die vorhandenen Routinen des GenProfi für Export und Import sind für eine derartige Datenübertragung leider wenig geeignet. Nach zahlreichen Versuchen und Irrtümern zeigte sich das Folgende: · Das Kopieren des Datenbestandes auf einen anderen Forschungsbereich dupliziert nur vollständig die Fehler des ursprünglichen Forschungsbereich. · Vor der Ausführung aller nachstehenden Optionen ist es unbedingt notwendig, im neu erzeugten Forschungsbereich zunächst die gleichen Einstellungen für die Erzeugung von Schlüsseln wie im ursprünglichen Forschungsbereich einzustellen. Gewiss werden die Schlüssel richtig übernommen, aber beim Öffnen eines Datensatzes werden dann automatisch die nicht gewünschten Schlüssel gebildet. Für meinen Zweck hatte ich von 20 möglichen Schlüsseln meist aus einer Kombination von Familienname, Vorname, Datum, Konfession, Sex einen eindeutigen Schlüssel durch eigene Eingabe gewählt. Dieser Schlüssel wird beim Personensatz sechsstellig aus dem Buchstaben I, möglichen Leerzeichen und der Indexnummer der Personendatei sowie beim Familiensatz fünfstellig aus dem Buchstaben F, möglichen Leerzeichen und dem Indexnummer der Familiendatei erzeugt. Sind erst einige Datensätze angelegt, wird bei Neuanlage von Datensätze automatisch der nächste freie Datensatz mit dem richtigen Schlüssel zur Verfügung gestellt. Sind zwischenzeitlich Sätze gelöscht worden, stehen diese freien Schlüssel ebenfalls wieder zur Verfügung. · Das Kopieren von Registern und Kennzeichen auf einen anderen Forschungsbereich muss der erste Schritt einer Abfolge von anderen Optionen sein. · Das Kopieren der Familiendaten vom ursprünglichen Forschungsbereich zu dem neuen Bereich ist der nächste Schritt. Dabei werden alle Familiendaten vollständig übernommen und nachfolgend im gleichen Arbeitsschritt die betroffenen Personensätze übernommen. · Das Kopieren aller nicht verbundenen Personen vom ursprünglichen Forschungsbereich zu dem neuen Bereich ist der nächste Schritt. Dabei werden im gleichen Arbeitsschritt auch alle Patenverknüpfungen übernommen. · Bei der Durchführung des vorgenannten Schrittes bleibt jedoch die Routine öfters hängen, und es erscheint die Meldung: Wiederholen, Übergehen oder Abbrechen. Wiederholen bringt dann überhaupt nichts, nur Übergehen. Obwohl ich mir die Abbruchstellen mit der jeweiligen Datensatznummer notiert hatte, zeigte sich oft, dass nicht nur ein einzelner Datensatz fehlte sondern ganze Bereiche. · Nach jedem dieser Schritte wurde die zeitaufwändige Optimierung durchgeführt, um sicher zu gehen, dass das Gesamtgebilde auch noch optimierbar bleibt. Noch immer befasse ich mich ausschließlich mit der Übertragung der in einer Kopie gesicherten Daten in eine neue Datenbank. Nach vielen Tagen und Nächten habe ich jetzt schon ein Gebilde, das hoffentlich alle Datensätze enthält. Die Frage der Vollständigkeit lässt sich nicht ohne weiteres beantworten, da die in der alten Datenbank die gelöschten Datensätze nicht tatsächlich gelöscht sind und bis zur Optimierung, die ja vorher leider nicht möglich war, weiter mit gezählt werden. Ich habe zunächst die Register kopiert und optimiert. Danach alle Familiensätze einschließlich der zugehörigen Personensätze, und wieder optimiert. Danach alle nicht verknüpften Personen einschließlich ihrer Patenbeziehungen, und wieder optimiert. Bei der anschließenden Sichtkontrolle zeigte sich dennoch, dass Tausende von Personensätzen nicht übernommen worden waren. Diese mussten also heraus gesucht und einzeln in die neue Datenbank kopiert werden. Und immer stand die Angst dahinter, dass danach die Optimierungsfähigkeit dieses Gebildes verloren gehen könnte. Jetzt habe ich alle mir erkennbaren Sätze übernommen und dabei auch gesehen, welche Datensatznummern frei gehalten wurden (ehemals gelöschte Sätze). Anfangs wurden die üblichen Register wie für Familiennamen, Vornamen, Orte, Regionen, Quellen., Berufe, Titel, Berufe, Krankheiten, Konfessionen, Länderkennzeichen, Sachgebiete und Aliase, die die Dateneingabe wesentlich erleichtern, beim Kopieren nicht übernommen. Jetzt habe ich endlich alle Register übernehmen können. Aber in gewissen Registern, die es gestatten, auf analoge Begriffe zu verweisen, wie: · das Ortsregister z. B. Schackummen = Eichkamp, Schakkummen = Eichkamp, oder sämtliche Stadtteile von Leipzig mit Klammer Leipzig sowie der Schreibweise für die Eingabe z. B. Lindenau-Leipzig und bei der Ausgabe Leipzig-Lindenau oder · bei Vornamen alle Varianten von Christel, Christiane, Christa, Kriste usw. = Chris oder · bei Familiennamen wie Josepait, Josepaite, Josupaitis, Josupeit, Josupaicze, Josupait, Josupaite, Josupaitis, Josupeit, Josupeitis, Joszupait, Joszupaitis, Jozupaite, Jozupaitis = z. B. Josepeit fehlen diese Klammerbegriffe. Diese Klammerbegriffe müssen nun neu von Hand eingegeben werden, da sie die Datenvielfalt zusammenhalten und erst einmal wirkungsvolle Suchbegriffe anzuwenden gestatten. Wegen der Größe dieser umfänglichen Register und der spezielle Suchroutinen, die unbedingt neu anzulegen sind, dauert dieser Vorgang unheimlich lange. Aber ich hoffe sehr, auf dem richtigen Weg zu sein. Solange diese Klammerbegriffe nicht gesetzt sind, kann ich nicht mit Sicherheit abprüfen, ob mir neue Daten schon bekannt sind. Und das Problem mit der ursprünglichen möglichen Übereinstimmung von Schlüsselbegriff und physikalischer Datensatznummer habe ich im Prinzip nur für die Familiensätze lösen können (wer zuerst kommt, bekommt die niedrigste freie Datensatznummer). Das bedeutet, dass ich so nach und nach für 195.663 Personensätze die Schlüssel an die jetzt vergebene Datensatznummer angleichen muss. Das ist deshalb wichtig, weil beim Anlegen eines neuen Personensatzes dann sofort die ursprüngliche Gleichheit von Schlüssel und Datensatznummer erreicht wird. In der Zwischenzeit arbeite ich mit Pseudo-Schlüsseln, die vorläufig ein "#" hinter der Zahl aufweisen, bis sie schließlich an der jeweils richtigen Stelle stehen, die aber im Augenblick noch von anderen Datensätzen besetzt ist. Nachdem nunmehr die Optimierung für das Gesamtbilde der Dateien gelungen ist, frage ich mich ernstlich, ob ich diese Sisyphus-Arbeit fortführen soll. Noch immer hoffe ich auf eine wirkungsvolle Hilfe, die den Ursprungszustand der erfassten Dateien wieder frei zugänglich und macht zwecks Minimierung der Dateigrößen die Optimierung der Datenbank ermöglicht. Ich hoffe, ich habe nicht allzu viel Müll geschrieben; aber im Augenblick fehlt mir einfach die Lust für ein nochmaliges Korrekturlesen. Mit freundlichen Grüßen Franz-Jörg Becker aus der Messestadt Leipzig e-Mail to: info(a)ahnen-pool.info Meine Datenbank ist - vielleicht auch durch Ihre / deine Hilfe - wie folgt gewachsen: ____________________________________________________________________________ "Der Ahnen - Pool" - Eine ostpreussische Datenbank vorwiegend für den Kreis Ebenrode (Stallupoenen) und teilweise seine Nachbarkreise. Sie enthaelt gegenwaertig in 195.653 Personen- und 56.072 Familiensaetzen auch Angaben ueber eingewanderte Kolonisten, die Flucht, Kriegsschauplaetze und neue Heimatorte in 19.159 Orten und Ortsteilen. ____________________________________________________________________________
Date: 2006/04/25 11:06:32
From: Eva Holtkamp <E.Holtkamp(a)onlinehome.de>
Lieber Herr Becker, haben Sie es schon mal mit PAF versucht? 195.663 Personensätze passen da locker 'rein. Ahnenwin von Dr. Reitmeier kann DOS einlesen, aber ich weiß nicht, ob man da diese Menge einlesen kann. Kann man die Datei nicht doch irgendwie splitten? Liebe Grüße Eva Holtkamp ----- Original Message ----- From: "Ahnen-Pool" <info(a)ahnen-pool.info> To: "'Genealogie-Programme'" <genealogie-programme(a)genealogy.net> Sent: Tuesday, April 25, 2006 10:13 AM Subject: [Gen-Programme] GenProfi 3.4 von Heiko Thimm Liebe Listenteilnehmer, bereits vor Jahren meldete ich mich schon einmal mit dem obigen Problem der nicht möglichen Optimierung von Daten aus GenProfi 3.4. Wenn ich auch heute nicht so recht glauben kann, dass Sie mir tatsächlich helfen können, ist es sicher gut, wenn man sich zumindest über die Probleme austauschen kann. Also, (auch für Nicht GenProfi-Nutzer) mein Ahnen-Pool arbeitet noch mit dem DOS-basierten GenProfi Version 3.4 von Heiko Thimm unter WindowsXP. Infolge des hohen konventionellen Speicherbedarfs sind einige Anpassungen in der autoexec.nt und in der config.nt für Speicherverwaltung und bei der Anzahl der Files erforderlich. Abgesehen von Meldungen bei der kontinuierlichen Dateneingabe wie „maximale Schachtelung erreicht“, die ein Schließen und Neuaufruf des Programms erforderlich machen, gab es sonst nie Probleme.
Date: 2006/04/25 12:49:32
From: Gerd Schmerse <gerd(a)schmerse.de>
Moin Ahnen-Pool, zur Mail vom Tue, 25 Apr 2006 10:13:21 +0200: >die Auffassung, dass die DOS-Technologie, auf der GenProfi 3.4 basiert, >nicht für über 195.000 Datensätze -- und schon gar nicht für das wiederholte >Speichern und Löschen von Datensätzen respektive einer potentiell >unendlichen Verschachtelungstiefe auf Datei-Basis ausgelegt ist. Das hat nichts mit der DOS-Technologie, sondern mit der Software zu tun. Z.B. verwaltet dBASE III plus für DOS etwa 10 Mio. Datensätze. >das so direkt auszudrücken: Aber stunden-, tagelange Wartezeiten -- egal für >welche Datenbank-Operation (Konvertieren, Exportieren, Kopieren ...) -- sind >bei einem Datenbestand von "bloß" 195.000 Datensätzen völlig inakzeptabel! DOS-Programme sind zumeist viel schneller als WINDOWS-Programme, zumals sie in Zeiten viel langsamerer Rechner entstanden sind und auf heutigen Rechners erstaunlich schnell laufen. Ich habe eine Datenbank mit 350.000 Datensätzen. Der Austausch eines Feldes in allen Datensätzen dauert etwa 10 Sekunden. Gruß Gerd (Schmerse)
Date: 2006/04/25 17:39:09
From: Stefan Mettenbrink <S.Metti(a)gmx.de>
Ahnen-Pool wrote:
fehlen diese Klammerbegriffe. Diese Klammerbegriffe müssen nun neu von Hand eingegeben werden, da sie die Datenvielfalt zusammenhalten und erst einmal wirkungsvolle Suchbegriffe anzuwenden gestatten.
Moderne Programme bieten dafür die Suche mit regulären Ausdrücken oder eine Ähnlichkeitssuche.
Noch immer hoffe ich auf eine wirkungsvolle Hilfe, die den Ursprungszustand der erfassten Dateien wieder frei zugänglich und macht zwecks Minimierung der Dateigrößen die Optimierung der Datenbank ermöglicht. Ich hoffe, ich habe nicht allzu viel Müll geschrieben; aber im Augenblick fehlt mir einfach die Lust für ein nochmaliges Korrekturlesen.
Ich denke, hier kann Dir nur der Entwickler helfen. Das wird sicher keine einfache Aufgabe sein. Allerdings wird nur der Entwickler alle nötigen Hintergrundinformationen haben um aus der defekten Datei wieder eine benutzbare zu machen (sofern möglich). Auch über die Vollsändigkeit sollte er dann etwas sagen können. Gerade bei einem so umfangreichen Datenbestand sehe ich hier zumindest eine "moralische" Verpflichtung des Programmierers. Als Anwender würde ich mir allerdings ebenfalls überlegen, in welchem Maße man eine solche Hilfe honoriert. Generell denke ich, dass es durchaus Programme gibt, die einen solchen Datenbestand bewältigen können. Die Mormonen werden mit PAF sicher deutlich mehr Daten bearbeiten. MfG, Metti.
Date: 2006/04/26 12:53:28
From: Gisbert Berwe <Berwe(a)web.de>
Hallo Herr Becker, es liegt vermutlich nicht an DOS, sondern daran, dass versucht wird, ein DOS-Programm unter XP laufen zu lassen. DOS wird, obwohl noch Bestandteil von XP, nur sehr unzureichend unterstützt. Ich bekomme in der letzten Zeit verstärkt defekte GenProfi-Dateien. Gen_Plus kann GenProfi-Dateien ünernehmen und bietet (im Vergleich zu GenProfi) noch weitergehende Möglichkeiten der Dateneingabe und auch der Suche, eben einfach 10 Jahre Entwicklung mehr. Wenn die Genprofi-Grunddatei, nicht die Index-Dateien, noch in Ordnung ist, kann ich die Daten übernehmen. Das Problem ist aber, und das haben Sie ja schon erkannt: "Sie müssen neues lernen". Ansonsten kann Ihnen nur Heiko Timm (vielleicht) weiterhelfen. Mit freundlichen Grüssen Gisbert (Berwe) Liebe Listenteilnehmer, bereits vor Jahren meldete ich mich schon einmal mit dem obigen Problem der nicht möglichen Optimierung von Daten aus GenProfi 3.4. Wenn ich auch heute nicht so recht glauben kann, dass Sie mir tatsächlich helfen können, ist es sicher gut, wenn man sich zumindest über die Probleme austauschen kann. Also, (auch für Nicht GenProfi-Nutzer) mein Ahnen-Pool arbeitet noch mit dem DOS-basierten GenProfi Version 3.4 von Heiko Thimm unter WindowsXP. Infolge des hohen konventionellen Speicherbedarfs sind einige Anpassungen in der autoexec.nt und in der config.nt für Speicherverwaltung und bei der Anzahl der Files erforderlich. Abgesehen von Meldungen bei der kontinuierlichen Dateneingabe wie "maximale Schachtelung erreicht", die ein Schließen und Neuaufruf des Programms erforderlich machen, gab es sonst nie Probleme.
Date: 2006/04/29 22:49:04
From: Ahnen-Pool <info(a)ahnen-pool.info>
Hallo Ihr Lieben, vor allem Eva Holtkamp, Gisbert Berwe, Stefan Mettenbrink und Gerd Schmerse, für die vielen Hinweise, Informationen, Meinungen und Ratschläge zu dem von mir geschilderten Problem der nicht durchführbaren Optimierung von GenProfi 3.4 - Daten bzw. der nicht durchführbaren Konvertierung zu GenProfi 4 - Daten. Dabei gab es wieder sehr viele und äußerst unterschiedliche Auffassungen zum DOS-System, zum Betreiben von DOS-Programmen unter Windows, zur jeweiligen Software und dem entsprechenen Betriebssystem, zu Programmen mit unterschiedlichen Datenbanksystemen, zur maximalen Satzzahl usw. usw., aber auch zur Übernahme in andere hilfreiche und stabile Genealogie-Programme sowie zur moralischen Verpflichtung des Entwickleres. Auch scheint mir nicht die vorhandene Anzahl der Datensätze der kritisiche Punkt zu sein, sondern vielmehr die Handhabung der Verknüpfungen innerhalb des Programms. Offenbar bündeln sich alle Schwierigkeiten in der Prgrammlogik von GenProfi, die offensichtlich derart komplex programmiert ist. Wie Herr Thimm selbst berichtete, ist die wesentliche Änderung, die mit GenProfi 4 angegangen wurde, um bekannte Probleme zu beheben (Speicherbedarf, proprietäres Memofeld, das keinen sauberen externen Zugang erlaubt u. a.), der Wechsel der Datenbankstruktur von xBase auf Foxpro. Mein Problem ist daher, dass ich sehr viele Jahre sehr zufrieden mit GenProfi 3.4. gearbeitet und einen beachtlichen Datenbankbestand durch fleißige Arbeit zusammen getragen habe. Und, da fast jeder weiß, dass man unheimlich viel in GenProfi hineinschreiben kann, was sich aber kaum durch auswertbare Dateien, Gedcom-Dateien für den Export usw. wieder herausholen lässt, entfiel für mich von vornherein ein Umstieg auf ein anderes Programm. Am meisten aber glaube ich, wurde GenProfi durch meine gezielte Anwendung der Register für Orte, Familiennamen und Vornamen mit Alias-Begriffen eingeschränkt. Und durch die besondere Struktur der Memo-Felder hat sich das Programm schließlich selbst erwürgt. Aber es wurde ja immer mit dieser Möglichkeit geworben. Eine mögliche Warnung ist mir nie zu Ohren gekommen. Allerdings falsche Verknüpfungen irgendwelcher Daten, die - wie mir z. B. Walter Wiesner berichtete - letztlich zum Zusammenbruch von GenProfi führten, hat es bei mir nie gegeben. Mit vielen Versuchen und Irrtümern ist es mir endlich gelungen, aus einzelnen Datenbankfraktionen ein neues Gebilde aufzubauen, das tatsächlich optimierbar ist. Meine Vorgehensweise zur Datenübertragung in einen neuen Forschungsbereich habe ich - wie bereits am 25.04.06 berichtet - in der Reihenfolge Register in neuen Forschungsbereich kopieren, dann Familiendaten und schließlich unverknüßfte Personen einschließ Patenbeziehungen kopieren, jeweils für eine bestimmte Anzahl von Datensätzen vor genommen und danach optimiert. Da wieder von vorn mit den nächsten Familien- und Personensätzen. Zum Schluß hatte ich eine (hoffentlich vollständige) Kopie des alten Forschungsbereichs, der sich anschließend optimieren und danach auch in das GP4-Format konvertieren ließ. Trotz meiner sicher recht gut durchdachten Vorgehensweise war aber in keinem Falle eine Vollständigkeit aller Datensätze ohne händisches Zutun zu erreichen. Hinzu kommt, dass die tatsächlichen Datensatzzahlen ja mehr oder minder im Dunkeln bleiben, da unzählige Datensätze beim normalen Datenbetrieb bei der Überarbeitung gelöscht werden, aber von der nicht optimierten Datenbank weiterhin in der Gesamtzahl der vorhandenen Datensätze ausgewiesen werden. Ansonsten wäre es eine einfache Differenzrechnung. Die hoffentlich weitgehend vollständige Datenbank habe ich dann tatsächlich mit der KONVGP34.EXE ins neue Datenbankformat von GenProfi 4 verwandeln können. Zuvor mehrfach durchgeführte Versuche mit der defekten Datenbank scheiterten weiterhin, weil auch diese Konvertierungsdatei wegen des scheinbar fehlenden Speicherplatzes ihre Arbeit nicht entfalten konnte. Der Ablauf ist dabei so, dass zuerst auf die DAT__AC.DBV zugegriffen wird (AC ist mein Forschungsbereich), und diese Datei hat sich ja schon mehrfach als defekt erwiesen (nicht mehr komprimierbar mit ZIP bzw. auch nicht mehr entpackbar, hin und wieder auch schwer kopierbar). Es ist jedenfalls eine Freude zu sehen, wie gut jetzt alles läuft. Optimierungen, die früher mehr als 4 Stunden dauerten, sind jetzt in etwa 10 Minuten erledigt. Allerdings muss ich einschränken, dass die von mir als Alias-Dateien benutzten Registerdateien für Familiennamen, Vornamen und Orte (ich hatte immer von Klammerbegriffen gesprochen) nur in der einfachen Grundform konvertiert wurden. So muss ich für eine effektive Suche nach und nach diese Klammerbegriffe neu eingeben. Und das kann dauern! In meinem Hinterkopf hat sich irgendwie der Gedanke festgesetzt, dass ich die alte Datenbank vielleicht durch die Überbeanspruchung dieser Alias-Begriffe in den Registern zum Erliegen gebracht habe. Und wenn man die defekte Datei mit irgendeinem Splitprogramm so weit zerlegen könnte, dass sich die einzelnen Teile optimieren lassen, könnte man die alte Struktur (Übereinstimmung von Datensatznummer und Personenschlüssel) erhalten und danach in GP 4 übernehmen. Bis jetzt funktioniert die Vergabe von neuen Personenschlüsseln bei der Anlage neuer Personensätze noch nicht richtig. Immer wieder werden Schlüssel vorgeschlagen, die wie sich erst beim Abspeichern des Datensatzes zeigt, bereits belegt sind. Andererseits wird auf die durch die wirkliche Löschung von Personensätzen frei gewordenen Schlüssel noch nicht zurückgegriffen. Im Falle der Familienschlüssel funktioniert es aber einwandfrei. Außerdem vergleiche ich jetzt durch Aufrufe der Personensätze in GenProfi 3.4 und Genprofi 4 (jeweils 15 Personensätze pro Bildschirm) nach und nach die Vollständigkeit bzw. mögliche Abweichungen in der Schlüsselbenutzung. Auch das ist bis für eine noch nicht absehbare Zeit eine ungeheure händische Aktion. Aber auf die Dauer will ich nicht beide Programme nebenher bedienen, weil sich so keine Einheitlichkeit erzielen lässt. Jetzt muss ich einmal sehen, ob ich irgendwo ein Hilfsprogramm downloaden kann, mit dem ich die Dateien mit der GP4-Struktur einsehen (und notfalls ändern) kann. Weiterhin schrieben mir einige Leser, dass Sie ebenfalls zwangsläufig auf GP4 umgestiegen sind und auch dafür viel Zeit aufwenden mussten. Die Zwangsläufigkeit verstehe ich aus eigenem Erleben. Ob sie mit dem großem Zeitaufwand die Datenrettung oder das Umlernen auf ein neues Programm meinen, weiß ich allerdings nicht. Ich empfinde das überhaupt nicht so. Und außer der wesentlich größeren Schnelligkeit, besonders für die Datenpflege springen mir keine erkennbaren Vorteile ins Auge. Kann es sein, dass ich noch nicht alle Vorteile von GP$ erkannt habe? Gibt es eigentlich auch GenProfi Extrem für das neue GP4-Format? Und was kann man damit anstellen? Nochmals Euch allen vielen Dank für Eure fachliche und moralische Unterstützung bei meinem Datenbankproblem. Schön wäre es jedoch, wenn zu einem solchen leistungsfähigen und hochgeschätzten Programm ein bessere Support möglich wäre. Mit freundlichen Grüßen Franz-Jörg Becker aus der Messestadt Leipzig e-Mail to: info(a)ahnen-pool.info Meine Datenbank ist - vielleicht auch durch Ihre / deine Hilfe - wie folgt gewachsen: ____________________________________________________________________________ "Der Ahnen - Pool" - Eine ostpreussische Datenbank vorwiegend für den Kreis Ebenrode (Stallupoenen) und teilweise seine Nachbarkreise. Sie enthaelt gegenwaertig in 195.960 Personen- und 56.073 Familiensaetzen auch Angaben ueber eingewanderte Kolonisten, die Flucht, Kriegsschauplaetze und neue Heimatorte in 19.159 Orten und Ortsteilen. ____________________________________________________________________________
Date: 2006/04/30 07:40:01
From: Heinz Bredthauer <Heinz.Bredthauer(a)t-online.de>
Ahnen-Pool schrieb: > Hallo Ihr Lieben, > Rest gelöscht > > Gibt es eigentlich auch GenProfi Extrem für das neue GP4-Format? Und was > kann man damit anstellen? > Hallo Franz-Jörg Becker, es gibt eine eigene Mailingliste zu GenProfi. Dort sind solche Fragen besser aufgehoben. Anmelden kann man sich mit einer mail an <genprofi-subscribe(a)yahoogroups.de>. Eine gute Hilfe bei Fragen zu GenProfi sind die Seiten von Ewald Wilck: <http://www.genprofi.info/unten_6.htm> und Robert Meyer: <http://www.genprofi-export.de.vu/> Hoffe geholfen zu haben Gruß aus Schleswig-Holstein (4°C, wolkig, zur Zeit trocken) Heinz