Absturz beim Erstellen Familienbuch

[Athos]

Hallo,

ich versuche schon seit längerem ein Familienbuch zu erstellen. Leider "stürzt" das Programm dabei ab.
Es ist dabei egal, ob ich über den Button "Buch" oder über "erstellen-Buch-Familienbuch" starte
Abbruch immer bei 3/4 des Laufbalkens (Bild 5)

Die vorgenommenen Einstellungen füge ich bei Bild 0 - 5

Mache ich etwas falsch oder ist im Programm ein Fehler. Leider gibt es keine Auswertungsmöglichkeit.

LG Athos

[Klaus Rothfeld]

Hallo Athos,
dieses Problem habe ich auch.
Es funktioniert nur wenn die Option alle Bilder nicht oder weniger Bilder gewählt werden, je nach Datenbankgröße.
Bei mir sind es 2247 Personen, 1750 Bilder, also ohne Bilder.
Es hängt mit der Speichernutzung des Programms zusammen.
Auf die Speichernutzung haben wir über Einstellungen/Optionen keinen Einfluss.

[DirkB]

Sollte das Problem ohne Bilder ebenfalls auftreten, dann mich gerne per Mail kontaktieren.

- Dirk

[Athos]

ohne Bilder klappt es.
Wenn ich ein Vorfahrenbuch erstelle mit allen Bildern dann klappt es . Warum hier ??????
Oder verstehe ich nicht den Unterschied zwischen Familienbuch und Vorfahrenbuch ? welcher besteht da denn ??
Das Datenvolumen ist doch bei beiden Varianten gleich.

Gibt es vom Programmierer eine Aussage zu diesem Problem?

[DirkB]

Wenn ich ein Vorfahrenbuch erstelle mit allen Bildern dann klappt es . Warum hier ??????
Oder verstehe ich nicht den Unterschied zwischen Familienbuch und Vorfahrenbuch ? welcher besteht da denn ??
Das Datenvolumen ist doch bei beiden Varianten gleich.

Ok, das habe ich nicht gewusst - ich wäre davon ausgegangen, dass das Datenvolumen nicht gleich ist.
Das heißt also, dass eine Ahnentafel in der Variante "mit allen Geschwistern" (sollte den Personen eines Vorfahrenbuchs entsprechen) exakt die Gesamtpersonenzahl deiner Ahnendatei entspricht (die alle im Familienbuch erscheinen)?

- Dirk

[ahnenarmin]

Hallo zusammen, hallo Dirk,

Dirk hat geschrieben: "Sollte das Problem ohne Bilder ebenfalls auftreten, dann mich gerne per Mail kontaktieren."

@Dirk:
Ich verstehe den Satz nicht so ganz. Bedeutet das, dass es mit (sehr vielen) Bildern ein Kapazitätsproblem geben kann, das außerhalb von AB liegt und damit "außerhalb" deiner Verantwortung liegt?

In diesem Fall sollte man die ungefähren möglichen Grenzen versuchen anzugeben. Es macht wenig Sinn "tausende" Bilder in AB zu erfassen, wenn man dann anschließend feststellen muss, dass ein Familienbuch (mit AB) nicht mehr erstellbar ist. Dann würde nur der Weg bleiben Fotos wieder zu löschen bis das Buch erstellbar ist. Das wäre nicht schön.

Gibt es da ggf. Kapazitätsproblem an der jeweiligen persönlichen Hardware?

Gruß
Armin

PS:
Mein Familienbuch mit ca. 19.500 Personen und ca. 400 Bildern und ca. 4450 Seiten wird innerhalb von 4-5 Minuten mit allen Fotos, Quellen und Notizen erstellt.
Meine *.ahn hat ca. 22 MB und die Media-Datei ca. 51 MB

[Kermet]

@Armin
Ahnenblatt ist eine alte 32-bit Anwendung und die haben mit großen Datenmengen ihre Probleme bei der Adressierung. Da gibt es zwar Möglichkeiten die Probleme in den Griff zu bekommen, diese sind aber nicht mehr zeitgemäß.
Der richtige Weg für Dirk wäre der Umstieg auf eine aktuelle Entwicklungsumgebung, mit Datenbank, 64-bit und objektorientierter Programmierung.
Dies ist neben einem gehörigen Know-how Aufbau auch mit einem nicht unerheblichen Zeitaufwand verbunden.

Ob Dirk diesen Schritt jemals machen wird weiß nur er, vielleicht sagt er etwas dazu.

[DirkB]

Ahnenblatt kann als 32-Bit-Anwendung maximal 4 GB des Hauptspeichers nutzen (unabhängig davon wieviel Hauptspeicher der Rechner hat). Wird mehr benötigt (egal ob bei Buch oder Tafel) gibt es eine Fehlermeldung wie hier ("Problem beim Erstellen eines Buchs"). Heißt aber im Umkehrschluss nicht, dass diese Fehlermeldung immer gleichbedeutend ist mit zu wenig Speicher. Theoretisch könnte auch eine "korrupte" Bilddatei oder eine inkonsistente Familienkonstellation einen solchen Fehler auslösen.

Der richtige Weg für Dirk wäre der Umstieg auf eine aktuelle Entwicklungsumgebung, mit Datenbank, 64-bit und objektorientierter Programmierung.

Hier werden spekulativ ein wenig Halbwahrheiten miteinander vermischt, ohne überhaupt zu wissen, was ich tatsächlich verwende.
Erstellung einer 64-Bit-Anwendung könnte helfen, ist aber auch kein Garant für alles. Dann ist vielleicht der Hauptspeicher kein Problem mehr, aber das Zeitverhalten ist dermaßen schlecht, dass man Stunden auf die Erstellung eines Buchs wartet.
Datenbank und objektorientierte Programmierung spielen in diesem Zusammenhang keine Rolle.
An dem Thema 64-Bit-Anwendung bin ich aber dran ...

Ich warte hier aber auch noch auf eine Antwort von Athos auf meine Frage ...

- Dirk

[Kermet]

Halbwahrheiten?
Nun als Informatiker kann ich dazu sagen, das große Datenmengen, wie die hier verwendeten Personendaten in einer Datenbank sicher besser aufgehoben wären.
In ganz seltenen Fällen, bei kleinen, stark verzeigerten Programmen von alten 4, 8, 16 oder 32-bit Programmen kann 64-bit langsamer sein, aber in aller Regel sind Anwendungsprogramme die in der ALU in einem Takt 64-bit verarbeiten schneller als die Verarbeitung von 32-bit.
Ist das nicht so, so liegt ein Fehler im Datenmodell oder der Programmstruktur vor.
Und die Objektorientierung würde vermeiden, dass immer wieder bei Programmänderungen Seiteneffekte auftreten. Es gibt bei Ahnenblatt ja kaum ein Programmupdate bei dem nicht neue Fehler auftauchen.

[torgau]

Halbwahrheiten?
Nun als Informatiker kann ich dazu sagen, das große Datenmengen, wie die hier verwendeten Personendaten in einer Datenbank sicher besser aufgehoben wären.
In ganz seltenen Fällen, bei kleinen, stark verzeigerten Programmen von alten 4, 8, 16 oder 32-bit Programmen kann 64-bit langsamer sein, aber in aller Regel sind Anwendungsprogramme die in der ALU in einem Takt 64-bit verarbeiten schneller als die Verarbeitung von 32-bit.
Ist das nicht so, so liegt ein Fehler im Datenmodell oder der Programmstruktur vor.
Und die Objektorientierung würde vermeiden, dass immer wieder bei Programmänderungen Seiteneffekte auftreten. Es gibt bei Ahnenblatt ja kaum ein Programmupdate bei dem nicht neue Fehler auftauchen.

Hallo Kermet,

Ahnenblatt verwendet nach meiner Ansicht auch eine Art Datenbank (selbst GEDCOM ist eine Art Datenbank). Selbst eine 32-bit-Zahl geht von 0 bis 4.294.967.296 (bzw. vorzeichenbehaftet von -2.147.483.647 bis 2.147.483.647), somit wird es erst bei Datenmengen größer 2 GB zum Problem. Bei der Programmierung ist es mit entscheidend, wie effektiv die Entwicklungsumgebung in der Lage ist aus dem Hochsprachenquellcode Maschinencode zu erzeugen. Ein 64-bit-Befehl braucht meist auch mehr CPU-Takte als ein 32-bit-Befehl und auf jeden Fall mehr Speicherplatz (Programm- und Datenspeicher). Objektorientierung ist auch kein Allheilmittel, das vor Programmfehlern schützt.
Ich bin studierter Automatisierungstechnik und programmiere seit ca. 40 Jahren (zwischen objektorientiert und Assembler / Backend, Echtzeitbetriebssystemebene, Prozessorebene).

Gruß Ulf

[Jo301]

Hallo zusammen,

die Datenmengen, über hier sinniert wird sind doch "Pillepalle" und für 32-Bit-Anwendungen keinerlei Problem.
Es ist auch keine Frage der Objektorientierung, der CPU, ihrer ALU oder anderer Spekulationen, so wie Dirk es auch ausdrückt. Das abstrahiert jede moderne Entwicklungsumgebung einfach so weg.

Freundlich würde ich sagen, dass Ahnenblatt "in die Jahre gekommen" ist. Im Fachjargon spricht man von Software-Erosion. Im Laufe der vielen Jahre kommt es zu strukturellen Verschlechterungen, die eine Pflege der Software zur "Herausforderung" machen.

Das ursprüngliche Design ist ausgereizt, die vielen Anpassungen über die Zeit schreien nach einem Neuansatz.
Man kann nichts mehr einfach ändern, ohne, dass andere Features beeinträchtigt werden.

Diese Seiteneffekte, die Kermet ebenso bestätigt, sprechen dafür. Die letzten Versionen, in denen zu Lasten von GEDCOM immer ein wenig und unvollständig "optimiert" wurde, sprechen für sich. Selbst das "Verhältnis" zu GEDCOM erodiert, während sich der Standard weiterentwickelt (GEDCOM v7).

Man kann eine erodierte Software mit einer proprietären Datenbank noch eine Weile am Leben erhalten, ja sicher. Die bessere Alternative wäre ein Neudesign, mit dem Wissen, was sich nach vielen Jahren einfach ansammelt. Es gäbe genug Baustellen, ich fange mit der Bedienoberfläche garnicht an.
Statt einer proprietären Datenbank wäre GEDCOM als Primärformat durchaus überlegenswert, das machen andere Projekte auch und eliminiert die Frage, was und ob man beim Im- und Export wie konvertiert.

Ob Dirk das alles als Alleinautor bewältigen kann und möchte?
Ganz ehrlich: Alles Gute von mir dazu! Ich würde Ahnenblatt gern verwenden, sehe das aber derzeit nicht mehr als realistisch an.

Gruß
Joachim

[Kermet]

Die reinen Textdaten sind sicherlich "Pillepalle" aber es kommen noch Bilddaten dazu und dann ist es nicht mehr "Pillepalle". Ich kann schon lange kein Familienbuch mit Bildern erstellen und andere melden das ebenfalls. Die Programmfehlermeldungen teilen das auch so mit.

Wer wie ich ein Ortsippenbuch erstellt und dabei der Versuchung erlegen ist, die vielen Personen auf den alten Bilden zu identifizieren und einzubinden, stößt bei Ahnenblatt an seine Grenzen. Sowohl beim Familienbuch als auch bei größeren Tafeln.

Sicherlich kann man sich proprietäre Datenbankstrukturen selber schreiben, aber es gibt ein Heer von Programmieren die sich ausschließlich mit Datenbanken, der effizienten Verwaltung und deren Zugriff beschäftigen. Ich unterstelle mal das derlei Datenbanken effizienter sind als selbstgestricktes.

Meiner Berufserfahrung nach sind 64-bit Entwicklungsumgebungen schneller als 32-bit, bei vergleichbaren Aufgaben.

Und natürlich sind (nicht mehr allzu) moderne Konzepte wie Objektorientierung, Vererbung, Kapselung, etc. kein Allheilmittel, aber sie vereinfachen eine saubere effiziente Programmierung ungemein.

[Jo301]

...Ich kann schon lange kein Familienbuch mit Bildern erstellen und andere melden das ebenfalls. Die Programmfehlermeldungen teilen das auch so mit.

Ergo gibt es das jetzige Design / Implementierung nicht her.
Ab wieviel Daten konkret inkl. Bilder klemmt es denn?

Wer wie ich ein Ortsippenbuch erstellt und dabei der Versuchung erlegen ist, die vielen Personen auf den alten Bilden zu identifizieren und einzubinden, stößt bei Ahnenblatt an seine Grenzen. Sowohl beim Familienbuch als auch bei größeren Tafeln.

Ich arbeite an und publiziere ein OFB bei CompGen, daher ist mir ein unverkrampftes Verhältnis zu GEDCOM wichtiger, zumal CompGen viele GEDCOM Tags selbstverständlich versteht oder der Admin mir sogar gern umsetzt. Bilder veröffentlicht dort niemand.

Ich habe vor Jahren einen eigenen GEDCOM-Parser implementiert, mit dem ich Spezialaufgaben insbesondere zur Qualitätssicherung umsetze.
Wobei GEDCOM als textuelles Format viele weitere Möglichkeiten bietet...

Sicherlich kann man sich proprietäre Datenbankstrukturen selber schreiben, ... unterstelle mal das derlei Datenbanken effizienter sind als selbstgestricktes.

Mit meiner Wortwahl "proprietäre DB" drücke ich implizit aus, dass man so heutzutage nicht mehr herangeht.
So erklärt sich für mich auch, dass GEDCOM auf eine relativ fixe DB zurecht gebogen wird, anstatt die DB zu reorganisieren...

Meiner Berufserfahrung nach sind 64-bit Entwicklungsumgebungen schneller als 32-bit, bei vergleichbaren Aufgaben.

Du meinst sicher das generierte Binary. Ja sicher läuft die Zeit der 32-Bit Applikationen langsam ab.
Obwohl es gut ist, wenn die Anwendung auf einer alten 32-Bit "Schreibmaschine" läuft.

... aber sie vereinfachen eine saubere effiziente Programmierung ungemein.

Ich habe aus rund 40 Berufsjahren viele Ansätze durch, zumeist auch in Gebieten, wo es wirklich drauf ankam und der Prozessaufwand zur Spezifikation, Umsetzung, Test, Dokumentation, Validierung und Zertifizierung enorm war.

Mein Fazit: Man spart nicht an Abstraktion, Kapselung und guter Methodik, es rächt sich (oft genug).

[DirkB]

Halbwahrheiten?
Nun als Informatiker kann ich dazu sagen, ...

Ich wollte deine Fachkompetenz nicht in Frage stellen, aber auch als Informatiker hast du lediglich spekuliert, wie wohl meine Entwicklungsumgebung aussieht, um mir einen Umstieg zu empfehlen. Ich nutze bereits eine aktuelle Entwicklungsumgebung und programmiere seit Jahren objektorientiert.
In meiner Entwicklungsumgebung kann ich z.B. High-DPI-Anwendungen erstellen ("gestochen scharfe Schriftdarstellung" auf z.B. Notebooks mit hoher Skalierung seit Ahnenblatt 4), was ich so noch bei keiner anderen Genealogie-Software gesehen habe.

In ganz seltenen Fällen, bei kleinen, stark verzeigerten Programmen von alten 4, 8, 16 oder 32-bit Programmen kann 64-bit langsamer sein, aber in aller Regel sind Anwendungsprogramme die in der ALU in einem Takt 64-bit verarbeiten schneller als die Verarbeitung von 32-bit.

In diesem Punkt hast du mich falsch verstanden. Ich wollte nicht sagen, dass 64-Bit-Anwendungen langsamer sind. Es ging mir darum, dass ohne Speicherlimit beliebig große (eventuell - wäre noch zu beweisen) Bücher erstellt werden können, die vielleicht neue Probleme mit sich bringen. Die Erzeugung von solchen Büchern (nennen wir es mal "Monsterbücher" mit vielen Tausend Seiten, was jetzt abbricht) dauert dann womöglich ziemlich lange (Ok, ist rein spekulativ - aber bei großen Vor-/Nachfahrenbüchern zeigen sich auch schon Performance-Mängel) oder es entstehen PDF- oder Word-Dateien unvorstellbarer Größe, die sich nicht mehr öffnen lassen (wer kennt hier schon die Limits?).

Freundlich würde ich sagen, dass Ahnenblatt "in die Jahre gekommen" ist. Im Fachjargon spricht man von Software-Erosion. Im Laufe der vielen Jahre kommt es zu strukturellen Verschlechterungen, die eine Pflege der Software zur "Herausforderung" machen.

Gefühlt verschwinden aktuell mehr Programme vom Markt, als dass neue hinzukommen. Oder gibt es irgendwelche namhaften Programme, die in den letzten 5 Jahre erst entstanden sind? Viele noch aktive Programme sind um die Jahrtausendwende entstanden und verwenden dementsprechend Programmteile und Funktionen die durchaus 20+ Jahre alt sind. Also kein Thema alleinig von Ahnenblatt.
Oder ist die Programmoberfläche gemeint? Da gibt es durchaus Programme, denen man es deutlicher ansieht, dass sie eine längere Entwicklungsgeschichte haben.

Es ist ja schon fast rührig, wie ihr euch um die Entwicklung sorgt und Tipps gebt, was man alles besser machen müsste.
Da würde mich nur noch mal interessieren, welche Genealogie-Software denn aus eurer Sicht aktuell die Modernste ist. Also eine Software, die nicht in die Jahre gekommen ist, objektorientiert mit Datenbank daher kommt. Für die Vergleichbarkeit bevorzugt eine Windows-Desktop-Software.

Zurück zu den Büchern und dem eigentlichen Problem hier im Beitrag:

Mein Familienbuch mit ca. 19.500 Personen und ca. 400 Bildern wird innerhalb von 4-5 Minuten mit allen Fotos, Quellen und Notizen erstellt.
Meine *.ahn hat ca. 22 MB und die Media-Datei ca. 51 MB

Ich finde solche Zahlen immer wieder beeindruckend - auch wenn andere Anwender hier vielleicht mit den Schultern zucken ...

@ahnenarmin: Wie viele Seiten hat dann das Familienbuch?

Vielleicht können andere Anwender mit größeren Datenmengen auch mal in dieser Form Ihre Spezifika benennen. Dann hätte man mal ein paar Vergleichswerte, was mit Ahnenblatt so möglich ist.

Auch wenn das bestimmt nicht die größte Datenmenge ist, mit der man mit Ahnenblatt ein Familienbuch erzeugen kann:
Kennt jemand eine Genealogie-Software, mit der man mit wesentlich mehr Personen (inkl. mehr Bilder) Familienbücher erstellen kann?

- Dirk