Daub Logo
Produkte Downloads Kaufen Company Community mein Daubnet
Anmelden

Community

Diskussionen, Fragen und Zusammenarbeit - hier ist der richtige Platz für den Austausch mit den Entwicklern und mit anderen Usern. Machen Sie mit!
Kostenloses Daubnet-Konto erstellen

Ages! Forum Allgemeines zu Ages! Fehlermeldung zur Ages! 2.10 Beta  


 

Fehlermeldung zur Ages! 2.10 Beta

 
 
 
Beitrag23. Mär 2016, 18:43
jcd hat geschrieben:Wenn Sie in der neuen Betaversion auf Probleme oder Fehler stoßen, melden Sie diese bitte hier in desem Thema.


Ich erhalte von Ages folgende Meldung/Aufgabe:
"Datum oder Verbindung unwahrscheinlich. Johann Everhard Blankenheim: hat den gleichen Namen wie ein älteres lebendes Geschwisterkind"
Das stimmt aber nicht, denn als das jüngere Geschwister am 01.10.1775 getauft wurde, war das ältere Geschwisterkind "vor 31.09.1775" bereits verstorben (siehe Anhänge). Die Ages-Meldung stimmt also nicht.

Auch in einer Reihe von anderen Fällen ist der Hinweis "Datum oder Verbindung unwahrscheinlich" unverständlich bzw. falsch und führt zu Irritationen und unnötigem Prüfaufwand. Hier ist in der Version 2.10 m.E. zu viel des Guten vorgesehen. Manchmal ist weniger besser.
hoschieicks
Dateianhänge
Ages Fehlermeldung2.jpg
Ages Fehlermeldung2.jpg (12.66 KiB) 4677-mal betrachtet
Ages Fehlermeldung1.jpg
 
 
 

Fehler beim Speichern im PDF-Format

Beitrag3. Apr 2016, 21:28
jcd hat geschrieben:Wenn Sie in der neuen Betaversion auf Probleme oder Fehler stoßen, melden Sie diese bitte hier in desem Thema.
Vielen Dank bereits im voraus für Ihre Mithilfe


Wenn ich eine Liste über Ages als PDF speichere, fehlt im PDF die Leerstelle zwischen Ereignis-Ort und zuständigem Amt.
Dateianhänge
Ages Liste Ereignis Ort_Amt markiert.jpg
Ages Liste Ereignis Ort_Amt markiert.jpg (5.57 KiB) 4613-mal betrachtet
Ages speichern PDF markiert.jpg
Ages speichern PDF markiert.jpg (5.07 KiB) 4613-mal betrachtet
 
 
 

Re: Fehlermeldung zur Ages! 2.10 Beta

Beitrag7. Apr 2016, 15:59
robbi hat geschrieben:Inzwischen habe ich festgestellt, dass das Feld LAYOUT NAME in der Layout Vorlage abgespeichert wird, bei der Speicherung als Favorit jedoch nicht übernommen wird.

Danke für den Nachtrag, jetzt ist nämlich klar was hier passiert: Als Favorit gespeicherte Ausgaben sind vom Layout abgekoppelt. Der Name des Layouts wird auch nicht mit dem Favorit mitgespeichert, weshalb beim Aufruf des Favoriten dann der Layoutname leer ist.


Joachim hat geschrieben:
jcd hat geschrieben:
Joachim hat geschrieben:Anmerkungen zum Dateistatus-Fenster:
1. das Fenster ist nicht aktiv, man kann es nicht per Tastendruck einfach schließen (ESC/ENTER/...)

Wann genau passiert das? In unseren Tests war das Fenster immer aktiv, und hat auf ESC reagiert.

Das passiert grundsätzlich immer nach dem Start des Programms, dass das Dateistatusfenster nicht aktiv ist, auch in Beta5.
(Snip)

Wir haben dies inzwischen nachstellen können. Mit Beta6 gibt es hier eine Änderung, die dem hoffentlich ein Ende bereitet.

Joachim hat geschrieben:Vorschlag: Die Farbe der höchsten enthaltenen Prio wählen, rot irritiert, wenn keine roten Aufgaben existieren.

Das hieße aber auch, dass wir im zweifel gelbe und graue Ausrufezeichen hätten... wie intuitiv das ist, ist fraglich.

Joachim hat geschrieben:
jcd hat geschrieben:
Joachim hat geschrieben:Tag 'FILE' exceeds the maximum length of 30 characters
http://www.daubnet.com/de/board/viewtopic.php?p=8568#p8568

Dies ist schlicht ein Fehler im Chronoplex GEDCOM Validator. Es gibt keine maximalen Feldlängen in GEDCOM.
Und was ist mit: MULTIMEDIA_FILE_REFERENCE:= {Size=1:30}
siehe Seite 53 Ihrer Übersetzung?

Sie meinen vermutlich, dass {Size=1:30} eine maximale Längenangabe für das Feld sei. Dem ist nicht so.
Die Feldgrößen zeigen die empfohlene Minimalgröße für Datenbanken, die längenbegrenzte Felder haben (Seite 41 oben)
Das bedeutet hier: GEDCOM-kompatible Programme sollten mindestens 30 Zeichen für Dateipfade speichern können. Ages! unterstützt deutlich längere Angaben - dies ist GEDCOM-konform. Die Macher hinter obigem "Validator" sind vermutlich dem gleichen Lesefehler aufgesessen.



Joachim hat geschrieben:
jcd hat geschrieben:Die Pfeiltasten funktionieren erst, nachdem der Eingabefokus per TAB (oder per Maus) an die Auflistung gewechselt wurde. Ohne diesen Wechsel navigieren die Pfeiltasten im Suchfeld.

Aber UP/DOWN nicht, sie könnte man intelligenter belegen, ENTER geht doch auch sofort. LEFT/RIGHT/BS sind natürlich im Suchfeld reserviert.

Pfeiltasten wirken unter Windows immer auf ein und das selbe Eingabefeld. Das ist Teil des Standard-UI.



Joachim hat geschrieben:
jcd hat geschrieben:Es ist nicht möglich, das Anlegen einer Aufgabe abzubrechen, sie wird in jedem Falle angelegt (notfalls mit leerem Text). Daher muss diese Änderung dann auch später gespeichert werden. Ich sehe im Moment keine schöne Lösung, um das Anlegen einer neuen Aufgabe abzubrechen.

Das müsste konzeptionell anders gelöst werden, neue Aufgaben sind nicht sofort ins GEDCOM einzutragen, sondern zunächst temporär in einem Array. Das Array wird dann erst bei Gültigkeit ins GEDCOM übertragen bzw. bei Abbruch verworfen.

Das Problem hier ist keinesfalls, dass wir nicht in der Lage wären, die Daten irgendwo zwischenzuspeichern, sondern dass das Aufgabenfenster ein sog. nicht-modales Fenster ist. Das heißt, dass es nach dem Öffnen gegebenenfalls stundenlang geöffnet bleiben kann, während völlig andere Fenster benutzt werden. In einem solchen Fenster ein "Abbrechen"-Knopf anzubieten ist dann nicht mehr nachvollziehbar. Was wird hier abgebrochen? Das Anlegen der Aufgabe? Die letzte Änderung? Fazit: was in einem modalen Fenster völlig harmlos und einfach ist (Anwender kann nichts anderes machen, bis er auf OK oder Abbruch geklickt hat) ist in einem nicht-modalen Fenster irritierend. Da wir gerade die Tatsache, dass die meisten Fenster in Ages! nicht modal sind als echtes Feature sehen, ist der Verzicht auf eine "Abbrechen"-Schaltfläche ein kleiner zu zahlender Preis.


Joachim hat geschrieben:Die Anforderung lautet präzisiert: "GEDCOM-RINs und andere Tags (anderer Genealogieprogramme), die Ages nicht selbst aktiv verwendet, sind beim Import zu entfernen. Deren Konsistenz und Intension kann ohnehin nicht aufrechterhalten werden (siehe Merge-Problem).

RIN-Kennzeichen auf Personenebene sind Teil des GEDCOM-Standards, und keine programmspezifischen Erweiterungen (welche Ages! aus Konsistenzgründen verwirft oder zu Notizen wandelt). Sollte MyHeritage hier Daten speichern, deren Konsistenz durch Beibehalten gefährdet würde, so wäre das eine "blöde Idee" auf deren Seite. Im Moment kann ich nicht beurteilen, ob dem so ist, weil ich nicht weiß, was deren Software anstellt, wenn man zwar die Datensätze neu durchnummeriert, aber die RINs (die im Übrigen keine @-Symbole beinhalten) so belässt.


Joachim hat geschrieben:Ist noch nicht gut bei Quellen: Bitte einmal Quellen öffen und Einfg, ESC und wieder Einfg betätigen. Beim zweiten Einfg geht es nicht mehr.

Erledigt mit Beta6


Joachim hat geschrieben:... dass Ages seinen eigenen zuvor gespeicherten Stand innerhalb des normalen GEDCOM-Kontextes korrigiert ist schon ein Problem.

Können Sie das genauer beschreiben?


robbi hat geschrieben:
Folgerichtig führt die umständliche Formel ... [snip] ... zum gewünschten Ergebnis

Der folgende Ausdruck ist "wahr" für alle Personen mit einem oder mehreren Ereignissen in dem Ort "Sehnde":
Code: Alles auswählen
EVENTMATCH("","","","Sehnde")



Friedel hat geschrieben:Altes Problem im Fenster Quelle/Quellverweise
Quellverweise->Eintrag->Felder: Datum der Aufz., Aufgez.Ereignis, Rolle
Die beiden letzten Felder lassen sich nicht bedienen.

Ages! lässt derzeit nur die Ereignisse zu, die im oberen Bereich (Reiter "Einträge") definiert wurden. Es wäre zu diskutieren, inwieweit die Eingabe eines Ereignisses beim Quellverweis davon unabhängig sein sollte. [0000792]


Friedel hat geschrieben:Fehler im Stammblatt
1. Fenster Notiz: Die Eingabe eines Zeilenwechsels (Return-Taste) schließt das Fenster

Behoben mit Beta 6.


Friedel hat geschrieben:Fehler im Stammblatt
2. Rahmen des Stammblattes: Die Bezeichnungen der Rahmen „Personen“ und „Partnerschaften“ am linken Rand sind abgeschnitten

Behoben mit Beta 6.


Friedel hat geschrieben:Fehler im Stammblatt
3. Rahmengröße: Wenn der Rahmen „Personen“ die Größe einer Seite überschreitet, dann wird zunächst als erste Seite eine Leerseite erzeugt und der alte Inhalt abgeschnitten auf der nächsten Seite angezeigt (altes Problem, oft diskutiert). Wird der Seiteninhalt noch größer, führt dies zu der Fehlermeldung „Abstract Error“ . Ages ist nicht mehr bedienbar und muss zwangsweise abgebrochen werden. Auch wenn Ages Rahmengrößen, die eine A4-Seite überschreiten, leider nicht erzeugen kann, darf dies nicht zu den erwähnten Reaktionen führen. Die einfachste Lösung ist, den Rahmeninhalt in solchen Fällen in der Darstellung abzuschneiden.

Ages! 2.10 kann (im Gegensatz zu älteren Versionen) Rahmen seitenübergreifend darstellen, so dass der Text auf die nächste Seite umbricht (bisher wurde dieser abgeschnitten). Einen "Abstract Error" konnte ich dabei nicht reproduzieren. Haben Sie eine "Anleitung", um den Fehler zu erzeugen?


Friedel hat geschrieben:Fehler Stammblatt
1. Überschriften
Löscht man den Namen einer Überschrift, so ist die Überschrift insgesamt verloren. Es gibt keine Möglichkeit, über die Feldliste die Überschrift wieder neu zu erstellen.

Löscht man alle Felder der Überschrift, so wird diese in der Tat nicht mehr angezeigt - das ist so gewollt. Es ist aber möglich, über den Menübefehl "Übschriften -> Standard" (od. ähnl) wieder eine neue Überschrift zu erzeugen.


Friedel hat geschrieben:Fehler Stammblatt
2. Rahmen Eltern/Partner 1/Kinder
Beispielfamilie: Vater, Partner 1, ein Elternteil, 5 Kinder
Aufruf Feldliste Eltern:
eine benutzerdefiniertes Feld darf nur unter Eltern erscheinen, wird aber nicht dort, sondern unter Partner1 und sämtlichen 5 Kindern dargestellt.
Aufruf Feldliste Ehen/Partnerschaften:
eine benutzerdefiniertes Feld darf nur unter Ehen/Partnerschaften erscheinen, wird aber sowohl unter Eltern, Partner1 und dem 2. Kind dargestellt.

Ages! nutzt für die Rahmen der Eltern, der Partner und der Kinder dieselbe Feldliste, daher führen Änderungen an dieser Liste zu änderungen in all diesen Rahmen. Wir überlegen, diese Rahmen zukünftig getrennt zu formatieren. [0000143]


web hat geschrieben:Bei Datum-Angaben bei Tod und Beerdigung erscheint in der Aufgabenprüfung:
"Datum muß zu Alter passen". Was ist für ein Algorithmus hinterlegt?

Wenn dem Ereignis (hier: Tod oder Beerdigung) eine Altersangabe hinterlegt wurde, und Ages! auf das Geburtsdatum rückrechnen kann, sollte das eingegebene Alter mit dem errechneten übereinstimmen. Diese Altersprüfung zielt derzeit immer auf den genauen Tag - eine Angabe des Alters nur in Jahren wird daher beanstandet, was nicht ideal ist. Aus diesem Grund ist diese Prüfung mit Beta6 zwar noch verfügbar, aber nicht mehr Teil der Standardbedingungen. ([0000378] wiedereröffnet)


ffw_wolli hat geschrieben:Grafikprobleme in der Bildschirmdarstellung:
Bitte mal die Screenshots ansehen, bei der Layout-Auswahl ist die Bildschirmdarstellung abgeschnitten/überlagert.

Wir haben solche Darstellungsfehler schon vereinzelt gesehen. Bisher konnten wir die Ursache leider noch nicht abstellen. [0000462] und [0000793]


Friedel hat geschrieben:Stammblatt Reihenfolge der Partnerschaften/Ehen
Wenn eine Person mehrfach verheiratet war, werden die Partnerschaften alphabetisch (Namen der Partner) und nicht chronologisch (entsprechend Heiratsdatum) geordnet dargestellt.
Gleiches trifft auf das Personenfenster im Feld Ehen/Partnerschaften zu.
Dieses Verhalten von Ages ist ziemlich irritierend und besteht schon in den Vorgängerversionen.

Ages! druckt die Partner in der Reihenfolge, die sie auch im Personenfenster einnehmen. Sollte kein Hochzeitsdatum bekannt sein, so ist diese Reihenfolge unter Umständen falsch - Sie müssten die Ehen dann per "Drag and Drop" in die richtige Reihenfolge ziehen. Das Personenstammblatt ändert sich dann entsprechend.


ChristianR hat geschrieben:a) Öffnen meiner Hauptdatei (in Ages! 2.04 editiert) mit 2.1 beta5
b) Abspeichern unter neuem Namen
c) Wiederöffnen dieser neuen Datei erzeugt einem mit ! markierten Importbericht
Line #27:unknown tag in submitter (SUBM): ADDR.CONC

selbiges für weitere 54 Zeilen im Bereich bis Line #139
Beim manuellen Vergleich der Dateiversionen 2.04 und 2.1b5 konnte ich kein Zeichen/Tag erkennen, der Probleme hervorrruft. Es scheint es so als füge 2.1b5 folgende Zeilen nach jeder "2 CONT [Text]" Zeile aus 2.04 ein:
2 CONC

Dies betrifft also Inhalte im Verfasser > Adresse Feld, bei welchem ich etwas mehr Infos zur Datei hinterlegt habe.
Werde die Dateien dem Support zusenden.

Behoben mit Beta 6


Joachim hat geschrieben:Die Beta5 erzeugte bei der Installation eine Warnung, die bei Beta4 nicht auftrat. Aus Win8.1:
2016-01-05_175020.jpg

Betaversionen werden von uns nicht signiert, was zu genau jener Warnung führen kann.


Joachim hat geschrieben:Ich bekommme relativ viele neue Aufgaben "Ereignisdatum muss zum Alter passen":
2016-01-09_173526.jpg

Das ergibt sich daraus, dass ich oft das Sterbealter aus den Kirchenbüchern übernommen habe, das Alter darin aber ungenau eingetragen wurde bzw. die Person hier im 6. Lebensjahr war. Zu der Zeit habe ich den Berechnen-Button nicht benutzt, aus dem sich ergibt:
2016-01-09_173553.jpg

Damit muss ich das an allen Stellen nachholen, was natürlich nervt. Andersrum trägt Ages das auch nicht automatisch ein, sofern die genauen Daten bekannt sind.
Vorschlag:
1. bei der Datenübernahme in die V2.1 die Altersangaben automatisch richtig korrigieren (und keine Aufgabe erzeugen)
2. die Altersangaben immer automatisch setzen, sobald möglich
Letzteres habe ich bei "My Family Tree" festgestellt, das Alter wird beim Import automatisch richtig berechnet und die "unkorrekten" Kirchenbuchangaben überschrieben.

Ages! wird die Altersangaben nicht automatisch korrigieren. Das letzte, was eine Ahnenforschungssoftware braucht ist eine Funktion mittels derer die Software eine mühsamen Eingaben des Anwenders verwirft. Gleichzeitig konnten wir mit diesem Betatest feststellen, dass die Prüfung zu viele "false positives" produzieret, weshalb wir sie bis auf weiteres aus dem Repertoir der Standardprüfbedingungen entfernen. [0000378]


Joachim hat geschrieben:Der Umbruch der Notizen ist nach der letzen Änderung noch nicht immer ok.
2016-01-09_172020.jpg

Im folgenden Beispiel einer Task müsste man das eine oder mehrere nachlaufende Leerzeichen entfernen.
2016-01-09_172332.jpg

Geändert mit Beta 6, bitte nochmal prüfen.


Ahnenheini hat geschrieben:In der Mobilversion (also ohne Installation) wird die alte Versionsnummer 2.0.4 angezeigt. ;-)

Dies ist mit Sicherheit die Version, mit der die Datei erzeugt wurde (Quellsystem), nicht die aktuelle Programmversion. Dort kann auch der Name eines völlig anderen Programmes stehen ;-)


Ahnenheini hat geschrieben:Desweiteren ist das Fenster für Ehen und Partnerschaften immer noch zu klein, wenn mehrere Ehen erfolgten. Kann man als Nutzer dieses Fenster nicht größer ziehen??

Ich konnte es für Beta6 ein klein wenig vergrößern. Selbst größer ziehen kann man es indes nicht.


Friedel hat geschrieben:Fehler Familienbuch
1.Seitenkopf
Jeder Versuch, die verfügbaren Felder der Feldliste zu nutzen, hat zur Folge, dass die nachfolgende Überschrift verschwindet.
2. Überschrift
Die Überschrift enthält fest eingetragen den Nachnamen des Probanden. Eine Änderung des Namens (beispielsweise voller Namen) ist offensichtlich nicht vorgesehen. Jeder Versuch, die verfügbaren Felder der Feldliste zu nutzen, hat zur Folge, dass die Überschrift verschwindet und nicht wieder herstellbar ist.

Das ist merkwürdig. Ich konnte das beschriebene Verhalten reproduzieren... bis eben. Da keine Änderung des Programmcodes durchgeführt wurde, kann es aber genausogut wieder auftauchen. Insofern kann ich im Moment nicht sagen, ob dieser Fehler mit Ages! 2.10 behoben sein wird, was mich mit Sicherheit mehr verwirrt, als Sie.

Friedel hat geschrieben:Stammblatt
Ein altes Problem: Nummerierung der Quellen.
In der Feldliste wird eine Nummerierung der Quellen angeboten. Erzeugt wird aber nur die Nummer 1 für jede Quelle. Wenn die Nummerierung aus welchen Gründen auch immer nicht implementiert werden kann, sollte die zugehörige Option in der Feldliste entfernt werden.

Die laufende Nummer beginnt pro Ereignis neu zu zählen. Der Begriff "laufende Nummer" ist etwas vage.


Iuncus hat geschrieben:
Joachim hat geschrieben:Ich bekomme relativ viele neue Aufgaben "Ereignisdatum muss zum Alter passen"

Bei mir taucht ein ähnlicher Fehler in Form von Aufgaben auf. Allerdings lässt er sich nicht korrigieren. Es handelt sich um mein eigenes Geburtsdatum. Ich habe das Datum gelöscht und erneut eingegeben und den Datensatz gespeichert. Die Fehlermeldung bleibt.


Kann es sein, dass AGES den Monat intern mit Buchstaben anstelle von Zahlen behandelt?

Nein, dem ist nicht so, was lässt Sie das vermuten? Sollte Ages! tatsächlich über das Alter bei der Geburt meckern, würde ich mir gern die Datei einmal ansehen. Bitte per Mail an: support@daubnet.com Danke. Abgesehen davon werden wir diesen Punkt vermutlich aus den Standardprüfkriterien streichen.


ffw_wolli hat geschrieben:Wenn ein gleiches Kind irrtümlich doppelt eingegeben wird, erscheint es tatsächlich nur ein mal mit Namen im Fenster "Kinder". [snip]

Vielen Dank für die ausführliche Beschreibung. Diesen Fehler konnten wir mit Beta6 beheben. [0000646]


Friedel hat geschrieben:Stammblatt, Reihenfolge der Ehen
Problem: Die zeitliche Reihenfolge der Ehen wird nicht immer korrekt dargestellt.
Beispiel:
Erste Ehe ist mit Datum „1796“ angegeben.
Die zweite Ehe ist mit Datum „vor 1796“ angegeben.
Es wird erst die Ehe von „1796“ und danach die Ehe „vor 1796“ dargestellt.
Problem besteht auch in Ages 2.04.

Ages! ist derzeit nicht in der lage, die beiden Ehen automatisch in die richtige Reihenfolge zu bringen. Die Sortierroutinen behandeln hier "1796" und "vor 1796" identisch. Wenn Sie per "Drag-and-Drop" etwas nachhelfen, und die Partner im Personenfenster in die richtige Reihenfolge schieben, ändert sich entsprechend auch der Ausdruck.


web hat geschrieben:Beim Einlesen eines jpg (oder tiff oder png) Bildes als Medium hängt sich Ages auf.

Normalerweise passiert dies selbstredend so nicht - wie genau gehen Sie vor? Können Sie die Bilder noch auswählen? Und gilt das für alle Bilder dieser Formate? Welche Version betrifft dies? Nur die Beta5 oder die reguläre 2.04?


Muntafuner hat geschrieben:List index out of bounds
Dieser (wiederholbare) Fehler ist auch in dieser Version noch vorhanden. [snip]

Danke auch hier für die detaillierte Beschreibung. Behoben in Beta6. [0000646]


ffw_wolli hat geschrieben:Hallo Montafuner,
mit Thread vom 02.02.16 habe ich dieses Problem schon ausführlich geschildert. Auch läßt es sich immer wieder reproduzieren. Was ich äußerst bedenklich finde ist die Tatsache, dass alle vor dem beabsichtigten Abspeichern hinzugefügten Datensätze unwiederruflich verloren sind. Noch bedenklicher finde ich die fehlende Reaktion des Entwicklers. Solche gravierenden Programmfehler müßten m.E. unverzüglich bereinigt werden. Nach anfänglich gut angelaufener Betaphase herrscht nun wieder Schweigen im Walde. Ich würde jetzt zumindest mal erwarten, dass über einen Zwischenstand des laufenden Betatests informiert wird.
Wolli

Es tut mir leid, wenn die Reaktionszeit nicht wie gewünscht ist. Dieser Post hier allein lässt vielleicht etwas vermuten, wieviel arbeit darin steckt, möglichst alle Fehler vor dem Release zu beheben.


Iuncus hat geschrieben:Hallo,
ich wollte einen neu angelegten und wiederholt problemlos zwischengespeicherten Datensatz abschließend speichern. Dabei erschien die folgende Fehlermeldung:
21-02-_2016_00-08-16.png

Danach lief ein paar Minuten lang das Windows Aktivitätssymbol.
Was bedeute diese Fehlermeldung? Es wäre gut, wenn die Hilfe-Seite eine Liste bereithalten könnte.

Die Fehlermeldung bedeutet, dass die Datei nicht geschrieben werden kann, weil sie durch ein Programm gesperrt wurde. Man kann dann die Datei (trotz "Sanduhr") unter anderem Namen speichern. Wir hatten ein ähnliches Problem in 2.04, welches eigentlich behoben sein sollte [0000608], daher habe ich zwei Fragen: a) geschah dies in der Beta5? und b) können Sie das reproduzieren?


hapu hat geschrieben:- In der Personenmaske ist der Begriff Bestattung gegenüber Geburt, Taufe Tod etwas zu klein geraten.
- "Totgeburt" als Todesursache ist ein Substantiv und sollte groß geschrieben werden. Ages erzwingt Kleinschreibung!
- "ertrunken" als Todesursache ist ein Partizip eines Verbs und daher klein zu schreiben. Ages will Großschreibung!
Erfreulich, daß die Zwangsleerzeile beim Abspeichern als Worddatei bei Ages 2.1 Beta nicht mehr passiert.
hapu

Je nach Bildschirmeinstellungen passt Ages! die Feldbezeichner automatisch in der Größe an, um noch in den Zwischenraum zwischen Rahmen und Eingabefeld zu passen. "Bestattung" ist die längste Bezeichnung der vier voreingestellten Ereignisse, ist dadurch zuerst betroffen. Dies ist kein Fehler.
Die Todesursachen sind weder in Groß- noch in Kleinschreibung in Ages! hinterlegt. Was hier passiert, ist dass Ages! per Auto-Vervollständigung automatisch auf Feldinhalte aus anderen Datensätzen zurückgreift. Habe ich also eine Todesursache "Kreas" statt "Krebs", so wird Ages! bei der Eingabe von "Kre" automatisch das "as" ergänzen, auch wenn dies ein Tippfehler ist. In Ihrem Falle bestehen die "Tippfehler" aus falscher Groß- oder Kleinschreibung, was leider besonders hartnäckig ist. Der "Trick" sieht wie folgt aus. Fügen Sie vor dem Wort ein Leerzeichen ein, korrigieren Sie dann das kleine "T" in ein großes. Löschen Sie dann das überflüssige Leerzeichen. Das ist zugegebener Maßen nicht besonders intuitiv [0000794]


Peter G. hat geschrieben:wo kann man etwas erfahren, wenn der Lizenzschlüssel nicht angenommen wird

Beim Support: support@daubnet.com


hapu hat geschrieben:Moin Moin

zu Aufgaben
Fehlermeldung Datum oder Verbindung unwahrscheinlich:
Anna Catharina Maria Köster: Geburt liegt normalerweise mindestens 14 Jahre nach Geburt des Vaters (Christoph Köster)
Das Mädchen wurde am 15.3.1755 geboren, der Vater errechnet 1720!
Wie könnte man wohl dem Programm einen Taschenrechner spendieren??
Leider kein Einzelfall.

hapu

Bitte prüfen, ob eine der Personen gegebenenfalls zwei verschiedene (konkurrierende) Geburtsdaten hat.


vknierim hat geschrieben:Unerwünschtes Überschreiben von Vornamen (Ages21Beta5)
Beim erstmaligen Aufruf von Ages! 2.10 Beta 5 mit einer existierenden Datenbank (ca. 6000 Individuen) trat folgender Fehler auf:
Sind im Dialog [Namen bearbeiten] im Feld [nach dem Namen] längere Einträge enthalten gewesen, wie z.B. "senior", "junior", "der Ältere" etc. werden diese ohne Weiteres in das Feld [Vorname(n)] kopiert und ersetzen die dort vorher vorhandenen Inhalte.
(Der Fehler trat nicht bei allen Namenszusätzen auf; Fehlersystematik noch nicht gefunden).

Bitte prüfen, ob bei diesen Namen gegebenenfalls als Kulturkreis "Nachname zuerst" angegeben ist, oder ob eine andere Systematik erkennbar ist. Mit Änderung [0000566] wurde hier die Speicherung nämlich verändert - ggf. muss diese noch überarbeitet werden.



Friedel hat geschrieben:Fehler von ages 2.04 und ages 2.1 beta
1. Zuordnung von Notizen zu Personen
Programmfenster: Bedienelement Notizen
Über das Bedienfeld „Notizen“ soll eine Liste aller im Stammbaum verwendeten Notizen und deren Zuordnung zu Personen dargestellt werden.
Bei einigen Notizen ist diese Zuordnung aber in den folgenden Fällen nicht gegeben.
(a) Heirat
Fenster: Quelle bearbeiten, Quellverweise
Alle Texteingaben mit dem Bedienfeld „Notizen“ werden zwar in der Liste aller Notizen angezeigt, im Feld zugeordnete Personen steht aber kein Eintrag.
Besonders ärgerliches Problem:
Es entsteht der Eindruck, dass die Notiz „verwaist“ ist und gelöscht werden könnte. Löscht man die Notiz aus der Liste, so ist die Notiz unweigerlich verloren, ohne dass man den Fehler erkennen kann. Er wird vielleicht zu einem viel späteren Zeitpunkt auffallen, wenn man die Notiz zu der betreffenden Person sucht, ohne zu wissen was der genaue Inhalt der Notiz war.
(b) Geburt/Taufe
Fenster: Quelle bearbeiten, Quellverweise
Alle Texteingaben mit dem Bedienfeld „Notizen“ werden zwar in der Liste aller Notizen angezeigt, im Feld zugeordnete Personen steht aber keine Person, sondern der Name der Quelle.
Dieser Fehler tritt schon in ages 2.04 auf.

In der Tat. Ages! hat Notizen zu Quellverweisen hinter Partnerschaftsereignissen hier anders behandelt als Notizen zu Quellverweisen hinter Personenereignissen - dadurch erschienen sie "verwaist". Korrigiert mit Beta6. Es bleibt zu debattieren, ob hier der Name der Person (bzw. bei Partnerschaftsereignissen der Name beider Personen) erscheinen soll, oder der Name der zugehörigen Quelle.


Friedel hat geschrieben:2. Zuordnung von Quellen zu Geburt/Taufe, Heirat etc.
Fenster: Quelle bearbeiten.
Liegen zu diesen Ereignissen keine Datums- und Ortsangaben vor (die betreffenden Felder sind leer), so ist die direkte Zuordnung von Quellen zu diesen Ereignissen zwar möglich, aber die unmittelbare Bearbeitung dieser Quelle (Quellverweise) ist es nicht. Die Felder sind für Eingaben blockiert.
Die Bearbeitung der Quelle muss abgebrochen werden. Die Quelle ist aber dem Ereignis zugeordnet. Erst wenn man die Quelle erneut aufruft, ist ihre weitere Bearbeitung möglich.
Dieser Fehler tritt schon in ages 2.04 auf.

Und träte ohne Ihre Meldung wahrscheinlich auch noch in 3.99 auf... das hätte ich so bestimmt nie getestet. Neben den ursprünglichen zwei Feldern muss man allerdings noch alle weiteren Felder im Fenster "Ereignis" leer lassen, um den Fehler zu reproduzieren. Behoben in Beta6.


Friedel hat geschrieben:3. Anmerkung zur Version Ages Beta 2.1x
Zur Zeit arbeite ich ausschließlich mit ages 2.04 und setze ages beta 2.1 nur für gelegentliche Tests ein. [snip]

So ist das auch geplant. Die Betaversion ist nur zum Testen gedacht. Wenn alles glatt geht, steht nicht mehr viel zwischen der heute veröffentlichten Beta6 und der finalen 2.10 - was dann das hin- und herspringen zwischen zwei Versionen hoffentlich erübrigt.



hoschieicks hat geschrieben:
Ich erhalte von Ages folgende Meldung/Aufgabe:
"Datum oder Verbindung unwahrscheinlich. Johann Everhard Blankenheim: hat den gleichen Namen wie ein älteres lebendes Geschwisterkind"
Das stimmt aber nicht, denn als das jüngere Geschwister am 01.10.1775 getauft wurde, war das ältere Geschwisterkind "vor 31.09.1775" bereits verstorben (siehe Anhänge). Die Ages-Meldung stimmt also nicht.

Auch in einer Reihe von anderen Fällen ist der Hinweis "Datum oder Verbindung unwahrscheinlich" unverständlich bzw. falsch und führt zu Irritationen und unnötigem Prüfaufwand. Hier ist in der Version 2.10 m.E. zu viel des Guten vorgesehen. Manchmal ist weniger besser.
hoschieicks

Vermutlich sind die beiden Kinder bei den Eltern nicht in der richtigen Reihenfolge vermerkt. Da die Sortierung der Kinder noch nicht optimal ist werden wir diese Prüfbedingung auch vorerst aus den Standardbedingungen entfernen.



hoschieicks hat geschrieben:Ich erhalte von Ages folgende Meldung/Aufgabe:
"Datum oder Verbindung unwahrscheinlich. Johann Everhard Blankenheim: hat den gleichen Namen wie ein älteres lebendes Geschwisterkind"
Das stimmt aber nicht, denn als das jüngere Geschwister am 01.10.1775 getauft wurde, war das ältere Geschwisterkind "vor 31.09.1775" bereits verstorben (siehe Anhänge). Die Ages-Meldung stimmt also nicht.

Auch in einer Reihe von anderen Fällen ist der Hinweis "Datum oder Verbindung unwahrscheinlich" unverständlich bzw. falsch und führt zu Irritationen und unnötigem Prüfaufwand. Hier ist in der Version 2.10 m.E. zu viel des Guten vorgesehen. Manchmal ist weniger besser.
hoschieicks

Aus einem mir nicht ganz verständlichen Grund stimmt der Zeichenabstand in PDF-Dateien bisweilen nicht zu 100% mit dem in Ages! überein. Bei unglücklichen Kombinationen von Buchstaben führt das dazu, dass der Text etwas länger dargestellt wird, und somit den eigentlich vorhandenen Leerraum zum nächsten Wort "auffrisst". Falls das bei Ihnen auftritt, versuchen Sie bitte eine andere Schriftart und/oder Schriftgröße.


Parallel zu diesem Post ging die neue Beta6 online. Ein Klick auf "auf Updates prüfen" sollte automatisch die neue Version herunterladen. Falls nicht (oder falls ein offline-PC die Betaversion erhalten soll) hier der Download
Ages 2.10 beta 6
Site Admin
jcd
 
 
 

Re: Fehlermeldung zur Ages! 2.10 Beta

Beitrag9. Apr 2016, 22:02
hoschieicks hat geschrieben:
Ich erhalte von Ages folgende Meldung/Aufgabe:
"Datum oder Verbindung unwahrscheinlich. Johann Everhard Blankenheim: hat den gleichen Namen wie ein älteres lebendes Geschwisterkind"
Das stimmt aber nicht, denn als das jüngere Geschwister am 01.10.1775 getauft wurde, war das ältere Geschwisterkind "vor 31.09.1775" bereits verstorben (siehe Anhänge). Die Ages-Meldung stimmt also nicht.

Auch in einer Reihe von anderen Fällen ist der Hinweis "Datum oder Verbindung unwahrscheinlich" unverständlich bzw. falsch und führt zu Irritationen und unnötigem Prüfaufwand. Hier ist in der Version 2.10 m.E. zu viel des Guten vorgesehen. Manchmal ist weniger besser.
hoschieicks

Vermutlich sind die beiden Kinder bei den Eltern nicht in der richtigen Reihenfolge vermerkt. Da die Sortierung der Kinder noch nicht optimal ist werden wir diese Prüfbedingung auch vorerst aus den Standardbedingungen entfernen.

hoschieicks hat geschrieben:Ich erhalte von Ages folgende Meldung/Aufgabe:
"Datum oder Verbindung unwahrscheinlich. Johann Everhard Blankenheim: hat den gleichen Namen wie ein älteres lebendes Geschwisterkind"
Das stimmt aber nicht, denn als das jüngere Geschwister am 01.10.1775 getauft wurde, war das ältere Geschwisterkind "vor 31.09.1775" bereits verstorben (siehe Anhänge). Die Ages-Meldung stimmt also nicht.

Auch in einer Reihe von anderen Fällen ist der Hinweis "Datum oder Verbindung unwahrscheinlich" unverständlich bzw. falsch und führt zu Irritationen und unnötigem Prüfaufwand. Hier ist in der Version 2.10 m.E. zu viel des Guten vorgesehen. Manchmal ist weniger besser.
hoschieicks


Aus einem mir nicht ganz verständlichen Grund stimmt der Zeichenabstand in PDF-Dateien bisweilen nicht zu 100% mit dem in Ages! überein. Bei unglücklichen Kombinationen von Buchstaben führt das dazu, dass der Text etwas länger dargestellt wird, und somit den eigentlich vorhandenen Leerraum zum nächsten Wort "auffrisst". Falls das bei Ihnen auftritt, versuchen Sie bitte eine andere Schriftart und/oder Schriftgröße.


hoschieicks hat geschrieben:
Zum ersten Post: Die beiden Kinder sind bei den Eltern in der richtigen Reihenfolge vermerkt, trotzdem erfolgt die Meldung/Aufgabe.

Zum zweiten Post: Hier ist die falsche Frage zitiert.

hoschieicks
 
 
 

Re: Fehlermeldung zur Ages! 2.10 Beta

Beitrag10. Apr 2016, 11:38
Friedel hat geschrieben:
Fehler im Stammblatt
3. Rahmengröße: Wenn der Rahmen „Personen“ die Größe einer Seite überschreitet, dann wird zunächst als erste Seite eine Leerseite erzeugt und der alte Inhalt abgeschnitten auf der nächsten Seite angezeigt (altes Problem, oft diskutiert). Wird der Seiteninhalt noch größer, führt dies zu der Fehlermeldung „Abstract Error“ . Ages ist nicht mehr bedienbar und muss zwangsweise abgebrochen werden. Auch wenn Ages Rahmengrößen, die eine A4-Seite überschreiten, leider nicht erzeugen kann, darf dies nicht zu den erwähnten Reaktionen führen. Die einfachste Lösung ist, den Rahmeninhalt in solchen Fällen in der Darstellung abzuschneiden.


Ages! 2.10 kann (im Gegensatz zu älteren Versionen) Rahmen seitenübergreifend darstellen, so dass der Text auf die nächste Seite umbricht (bisher wurde dieser abgeschnitten). Einen "Abstract Error" konnte ich dabei nicht reproduzieren. Haben Sie eine "Anleitung", um den Fehler zu erzeugen?


Das Problem liegt sehr wahrscheinlich in dem von mir verwendeten Layout verborgen. Ich benutze verschiedene, um Darstellungen und Rechenfelder zu testen. Eines dieser Layouts befindet sich im Anhang. Anstelle Stammblatt heißt das Layout Personenblatt.
Dateianhänge
Personenblatt-1-Standard.AgesReportLayout
(65.79 KiB) 352-mal heruntergeladen
 
 
 

Re: Fehlermeldung zur Ages! 2.10 Beta

Beitrag11. Apr 2016, 15:48
Fehlermeldung zur Ages! 2.10 Beta

Fehler im Stammblatt
Beispielfamilie: Eine Frau, ein uneheliches Kind
Im Personenfenster Ehen/Partnerschaften ist der Status auf „unverheiratet“ gesetzt (unbekannter Partner). Die Felder Hochzeit etc. sind leer.

Fehlerbeschreibung (Ages 2.04 und 2.10beta)
1. Im Stammblatt wird in diesem Fall lediglich eine Überschrift angezeigt (Partner1). Der Zugriff auf die Feldliste für Partnerschaften ist nicht möglich.
2. Alle Einträge unter Lebenslauf, Quellen, Notizen werden im Stammblatt nicht angezeigt.

Die Tatsache, dass eine Person unverheiratet ist, impliziert nicht, dass es keine Aussagen zu der Lebenssituation „unverheiratet“ gibt, wie Lebenslauf, Quellen, Notizen…
 
 
 

Re: Fehlermeldung zur Ages! 2.10 Beta

Beitrag11. Apr 2016, 19:11
Bei der Datenschau ist mir aufgefallen, dass Beziehungen mal mit dem Tag RELA und anders wieder mit _RELA angegeben werden.

Fall 1:
2 _ASSO @I955@
3 RELA GODPARENT

oder Fall 2:
1 ASSO @I197@
2 RELA DISTINCT_FROM

Ich habe den Verdacht, dass dies nicht korrekt ist, im Fall 1 sollte doch "RELA" verwendet werden und im Fall 2 "_RELA", da es eine Ages-spezifische Erweiterung des Standards ist (Ausblenden von Personen).

Nachtrag:
Der Sachverhalt ist hier erklärt:
http://www.daubnet.com/de/board/viewtopic.php?f=28&t=1759

Ich frage mich nur, warum ein Standard Tag ASSO mit "2 RELA DISTINCT_FROM" benutzt wird. DISTINCT_FROM habe ich im Standard nicht gefunden. Da das Ausblenden in Zusammenhang mit dem Mergen notwendig wird, wäre eine Ages-spezifische Umsetzung in einem _MERGE Block (z.B.) (wie die Aufgaben) wahrscheinlich die langfristig bessere Lösung. Aber das ist natürlich nicht mal eben umgesetzt.
Da es beim Mergen noch Entwicklungsbedarf gibt, muss das konzeptionell zusammen betrachtet werden.
Zuletzt geändert von Joachim am 17. Apr 2016, 17:47, insgesamt 1-mal geändert.
 
 
 

Re: Fehlermeldung zur Ages! 2.10 Beta

Beitrag12. Apr 2016, 12:46
Friedel hat geschrieben:Fehler von ages 2.04 und ages 2.1 beta
1. Zuordnung von Notizen zu Personen
Programmfenster: Bedienelement Notizen
Über das Bedienfeld „Notizen“ soll eine Liste aller im Stammbaum verwendeten Notizen und deren Zuordnung zu Personen dargestellt werden.
Bei einigen Notizen ist diese Zuordnung aber in den folgenden Fällen nicht gegeben.
(a) Heirat
Fenster: Quelle bearbeiten, Quellverweise
Alle Texteingaben mit dem Bedienfeld „Notizen“ werden zwar in der Liste aller Notizen angezeigt, im Feld zugeordnete Personen steht aber kein Eintrag.
Besonders ärgerliches Problem:
Es entsteht der Eindruck, dass die Notiz „verwaist“ ist und gelöscht werden könnte. Löscht man die Notiz aus der Liste, so ist die Notiz unweigerlich verloren, ohne dass man den Fehler erkennen kann. Er wird vielleicht zu einem viel späteren Zeitpunkt auffallen, wenn man die Notiz zu der betreffenden Person sucht, ohne zu wissen was der genaue Inhalt der Notiz war.
(b) Geburt/Taufe
Fenster: Quelle bearbeiten, Quellverweise
Alle Texteingaben mit dem Bedienfeld „Notizen“ werden zwar in der Liste aller Notizen angezeigt, im Feld zugeordnete Personen steht aber keine Person, sondern der Name der Quelle.
Dieser Fehler tritt schon in ages 2.04 auf.

In der Tat. Ages! hat Notizen zu Quellverweisen hinter Partnerschaftsereignissen hier anders behandelt als Notizen zu Quellverweisen hinter Personenereignissen - dadurch erschienen sie "verwaist". Korrigiert mit Beta6. Es bleibt zu debattieren, ob hier der Name der Person (bzw. bei Partnerschaftsereignissen der Name beider Personen) erscheinen soll, oder der Name der zugehörigen Quelle.


Meiner Meinung nach müssen die Notizen den Personen zugeordnet werden und nicht den Quellen. Die Zuordnung von Notizen zu Quellen ist in den oben aufgeführten Fällen nicht eindeutig!
Eine Quelle (z.B. Geburtsregister Frankfurt) kann Einträge völlig verschiedener Personen enthalten. Ein Quellverweis ist ein individueller und eindeutiger Bezug auf diese Quelle. Eine Notiz zu einem Quellverweis ist eine individuelle Aussage bezogen auf diesen Quellverweis und der damit verbundene Person!
Allerdings kann man natürlich aus Person und Quelle in der Liste der Notizen anzeigen.

Friedel hat geschrieben:Altes Problem im Fenster Quelle/Quellverweise
Quellverweise->Eintrag->Felder: Datum der Aufz., Aufgez.Ereignis, Rolle
Die beiden letzten Felder lassen sich nicht bedienen.

Ages! lässt derzeit nur die Ereignisse zu, die im oberen Bereich (Reiter "Einträge") definiert wurden. Es wäre zu diskutieren, inwieweit die Eingabe eines Ereignisses beim Quellverweis davon unabhängig sein sollte. [0000792]


Es ist jedoch so, dass das Zusammenspiel zwischen den Einträgen im oberen Bereich (Reiter „Einträge“) und den Einträgen im unteren Bereich (Reiter „Eintrag“) sehr fehlerhaft ist. Es fällt mir schwer die verschiedenen Effekte vollständig zu beschreiben.
Einige Fehlerbeispiele:
1. Die Felder unter „Einträge oben“ und „Eintrag unten“ sind leer
Bezieht man sich im Stammblatt auf das Feld „alle Ereignisse->Quellen->Aufgez. Ereignis“ im unteren Bereich, so wird der Text „alle Ereignisse“ dargestellt.

2. Die Felder unter „Einträge oben“ und „Eintrag unten“ sind mit Daten belegt
Löscht man die Feldinhalte unter dem Reiter „Einträge“ im oberen Bereich, dann bleiben alle Einträge unter dem Reiter „Eintrag“ im unteren Bereich erhalten, ohne die Möglichkeit zu haben, die Feldinhalte von „Aufgez. Ereignis“ und „Rolle“zu löschen. Bezieht man sich im Layout eines Stammblattes auf diese Felder, so werden zwangsweise Daten angezeigt, die man nicht haben will. So wird für „Aufgez. Ereignis“ wieder der Text „alle Ereignisse“ angezeigt.
Das alles wird begleitet von einem eratischen Verhalten von Ages beim Anklicken der Felder.

Programmfenster: Reiter Notizen, Fehler Anzeige der Notizen


Wenn in einer Notiz ein Zeilenumbruch auftritt, wird die betreffende Notiz nur bis zum Zeilenumbruch angezeigt.
 
 
 

Re: Fehlermeldung zur Ages! 2.10 Beta 5 und 6

Beitrag16. Apr 2016, 10:21
Iuncus hat im Februar 2016 geschrieben:
ich wollte einen neu angelegten und wiederholt problemlos zwischengespeicherten Datensatz abschließend speichern. Dabei erschien die folgende Fehlermeldung:
21-02-_2016_00-08-16.png
Danach lief ein paar Minuten lang das Windows Aktivitätssymbol.
Was bedeute diese Fehlermeldung? Es wäre gut, wenn die Hilfe-Seite eine Liste bereithalten könnte.
Antwort jcd:
Die Fehlermeldung bedeutet, dass die Datei nicht geschrieben werden kann, weil sie durch ein Programm gesperrt wurde. Man kann dann die Datei (trotz "Sanduhr") unter anderem Namen speichern. Wir hatten ein ähnliches Problem in 2.04, welches eigentlich behoben sein sollte [0000608], daher habe ich zwei Fragen: a) geschah dies in der Beta5? und b) können Sie das reproduzieren?

1. Der Fehler erscheint sowohl in der Beta 5 als auch in der Beta 6 Version.
2. Die Fehlermeldung blieb in der Beta 6 mit geändertem Dateinamen bestehen.
Erst nach den Schließen von AGES verschwand die Message Box.
3. Der Fehler trat auf, nachdem ich zwei Dateien miteinander verschmolzen
hatte und die erweiterte Datei speichern wollte.
4. Nach der "Aktion" blieb eine gespeicherte Datei in dem mit dem Browser-
fenster eingestellten Verzeichnis zurück.
 
 
 

Re: Fehlermeldung zur Ages! 2.10 Beta

Beitrag16. Apr 2016, 19:11
jcd hat geschrieben:... Umbruch... Geändert mit Beta 6, bitte nochmal prüfen.
Der Umbruch hat immer noch Tücken.
Die Zeile mit "1 CONC " ist weg, dafür rutscht das Leerzeichen an das Ende der vorhergehenden Zeile.
2016-04-13_184830.png
(6.9 KiB) Noch nie heruntergeladen


Es gibt auch aufeinander folgende CONC Zeilen, die beide mit Leerzeichen enden.
2016-04-13_185913.png


jcd hat geschrieben:Das bedeutet hier: GEDCOM-kompatible Programme sollten mindestens 30 Zeichen für Dateipfade speichern können. Ages! unterstützt deutlich längere Angaben - dies ist GEDCOM-konform. Die Macher hinter obigem "Validator" sind vermutlich dem gleichen Lesefehler aufgesessen.
Das kläre ich direkt mit dem Autor, ich konnte dort schon mehrere Verbesserungen einbringen.

Joachim hat geschrieben:Die Anforderung lautet präzisiert: "GEDCOM-RINs und andere Tags (anderer Genealogieprogramme), die Ages nicht selbst aktiv verwendet, sind beim Import zu entfernen. Deren Konsistenz und Intension kann ohnehin nicht aufrechterhalten werden (siehe Merge-Problem).
jcd hat geschrieben:RIN-Kennzeichen auf Personenebene sind Teil des GEDCOM-Standards, und keine programmspezifischen Erweiterungen (welche Ages! aus Konsistenzgründen verwirft oder zu Notizen wandelt). Sollte MyHeritage hier Daten speichern, deren Konsistenz durch Beibehalten gefährdet würde, so wäre das eine "blöde Idee" auf deren Seite. Im Moment kann ich nicht beurteilen, ob dem so ist, weil ich nicht weiß, was deren Software anstellt, wenn man zwar die Datensätze neu durchnummeriert, aber die RINs (die im Übrigen keine @-Symbole beinhalten) so belässt.
Den Effekt habe ich lediglich mit der Datei meiner Frau, sie hat mal mit dem FTB angefangen dann aber später mit Ages weiter erfasst. Ein Zurück zu MyHeritage ist nicht geplant. Tags, die Ages nicht benutzt, machen für mich keinen Sinn und sind nur Ballast. Zudem keiner von uns weiss, wozu sie gut sind und es geht prima ohne diese. Das kann ich mit meinem GedCnv-Programm auch bereits selbstverantwortlich entfernen.
http://www.daubnet.com/de/board/viewtopic.php?p=8774#p8774

In den von mir nur mit Ages erfassten Daten sind keine RIN-Tags enthalten.

Aus den Standard 5.5.1:
"Das RIN-Kennzeichen ist ein Datensatzidentifizierer, der dem Datensatz durch die erstellende Software zugewiesen wird. Seine beabsichtigte Aufgabe ist die automatische Zuordnung eines Datensatzes bei zurückkehrenden Transaktionen oder anderen Abstimmungsprozessen."

"RIN {REC_ID_NUMBER}:= (Datensatzidentifikation) Von einem automatisierten Ursprungssystem automatisch zugewiesene Nummer, die vom empfangenden System dazu benutzt werden kann, Ergebnisse mit Bezug auf diese Nummer auszugeben."

Die REC_ID_NUMBER ist im Standard nicht weiter definiert und wird nur vom "automatisierten Ursprungssystem", in dem Fall Myheritage "verstanden".

Offensichtlich dienen sie den s.g. Smart-Matches, die aber nur innerhalb von MeHeritage funktionieren und vermutlich eine proprietäre Lösung sind.

Joachim hat geschrieben:... dass Ages seinen eigenen zuvor gespeicherten Stand innerhalb des normalen GEDCOM-Kontextes korrigiert ist schon ein Problem.
jcd hat geschrieben:Können Sie das genauer beschreiben?

Die Beta5 generierte ja bekanntlich viele Aufgaben, danach musst man einmal speichern, soweit richtig. Beim nächsten Öffnen wurden dann nochmals ein paar Tags umgeordnet und ein einmaliges weiteres Speichern war notwendig.

Das tritt mit der Beta6 derzeit nicht auf, das hing ggf. mit der erweiterten und nun entschärften Prüfung zusammen. Ich melde mich, wenn ich das reproduzieren kann.

jcd hat geschrieben:Altersberechnung...
Ages! wird die Altersangaben nicht automatisch korrigieren. Das letzte, was eine Ahnenforschungssoftware braucht ist eine Funktion mittels derer die Software eine mühsame Eingaben des Anwenders verwirft.
Das ist ja definitiv nicht der Fall, wenn man die Anforderung richtig versteht unter
http://www.daubnet.com/de/board/viewtopic.php?f=28&t=2347

Bei mehreren Tausend erfassten Personen sind nicht von Anfang an die notwendigen Daten vorhanden, es entwickelt sich. Irgendwann ist man drauf angewiesen, sich durchzuklicken und holt die Altersberechnung mühsam nach, sofern die Daten dafür komplett sind (genaues Geburtsdatum + genaues Sterbedatum oder Geburts- und Heiratsdatum).

Solange die Daten nicht vollständig sind, bleiben die manuell eingetragenen Altersangaben (mit natürlicher Ungenauigkeit) erhalten.

Wie es geht, habe ich in meinem GedCnv-Programm konzeptionell umgesetzt und es funktioniert sehr gut.
Fehlt nur eine Klicki-Bunti-Oberfläche, ... wenn ich mal Zeit dafür habe.

Was spricht dagegen, eine Alterskorrektur dem Anwender in einem Tools-Menü optional anzubieten?

jcd hat geschrieben:Gleichzeitig konnten wir mit diesem Betatest feststellen, dass die Prüfung zu viele "false positives" produziert, weshalb wir sie bis auf weiteres aus dem Repertoir der Standardprüfbedingungen entfernen.
Das war zu gut gemeint und "nobody is perfect".
Aber wie soll sich das ohne Alterskorrektur lösen lassen? Entweder es wird nie eine Aufgabe generiert, wenn es nicht genau stimmt oder das Alter wird generiert, wenn die Daten vorliegen.

Bei der nach Beta5 recht langen Aufgabenliste ist mir aufgefallen, dass die Orientierung darin ohne laufende Nummer (im Fenster und in der Druckliste) recht mühsam ist. Eine Nummer oder weitere Verbesserung des Formats sollte überlegt werden.

Ich habe und werde noch Wünsche einstellen unter:
http://www.daubnet.com/de/board/viewtopic.php?f=9&t=2353
 
 
 
 
 
cron