forum Ancestrologie
Ancestrologie - Développement => Développement => Discussion démarrée par: DDdeBerdeux le 15 Mars 2007 à 11:13:15
-
Bonjour,
Avant d'officialiser ces nouvelles versions, on voudrait avoir votre avis.
Le lien pour le téléchargement de la mise à jour de la base en version b5.016 (ou outil de migration de la base) est ICI (http://andre.langlet.free.fr/ancestro/maj_b357_b5017.exe) et la base vide accompagnée de la liste complète des modifications LA (http://andre.langlet.free.fr/ancestro/FAMILLEVIDE5017.zip).
J'ai aussi mis en ligne ICI (http://andre.langlet.free.fr/ancestro/maj_v695_b5017.exe) une version de l'exécutable de migration qui met également à jour l'exécutable ancestrologie.exe en V695. Ceci dans le but de répondre aux utilisateurs qui trouvent compliqué de devoir faire 2 manipulations lors d'une mise à jour. J'aimerai avoir votre opinion. Pour ma part je suis assez mitigé, car les 2 autres maj séparées étant toujours nécessaires, cette méthode ajoutée risque également de perturber des utilisateurs. Cumulant les 2 maj, ce fichier fait 8 Mo.
Les maj de la base en b5.016 concernent:
Modification procédure de migration: plus qu'une seule optimisation si la base est à une version 5.000 ou supérieure.
Mise à jour Firebird embedded en version 2.0.1 RC2
Essai de regroupement des maj du logiciel et de la base.
Ajout aux PROC_DATE_WRITEN et PROC_DATE_WRITEN_UN d'un champ VALIDE permettant le contrôle de la validité de la date en particulier depuis le logiciel, lors de la saisie.
Ajout index sur champs TYPE_TOKEN,ID de REF_TOKEN_DATE pour accélérer les procédures ci-dessus.
Dans le logiciel V695:
Réparation du problème du format d'affichage des détails de l'événement historique.
Dans ajout d'une ville depuis l'index des lieux, classement des pays et régions en ordre alphabétique. Idem depuis lieux favoris, détails de la ville.
Dans fiche de saisie rapide, si le sexe est présélectionné (conjoint, père, mère), seuls les prénoms du sexe figurent dans la liste de choix.
Le contrôle de la date lors de la saisie utilise maintenant la procédure PROC_DATE_WRITEN stockée dans la base.
Plus d'autres corrections que j'ai oubliées...
Bon tests.
André
Mise à jour du 19/03/2007 Base en version b5.017 avec utilitaire de visualisation des incohérences sur les âges dont le fichier d'installation est à télécharger ICI (http://andre.langlet.free.fr/ancestro/InstIncoherences.exe)
-
Bonjour André,
Au début de ton message, il faudrait corriger la version de base: b5.016 au lieu de b5.0156.
On essaye tout cela et on en reparle.
-
Bonjour André,
En son temps j'avais regroupé quelques anomalies en attente de corrections. La version v695 combinée avec b5.016 apporte beaucoup de réponses.
Anomalies en suspens sur V693:
Saisie des dates dans la fiche de saisie rapide
Résolu: Le contrôle de la saisie des dates est redevenu opérationnel aussi bien sur les dates saisies en numérique qu'en littéraire. Le contrôle porte également sur les mots clefs.
Le fontionnement n'est pas simple à comprendre:
-1- Je crée un enfant, je complète le prénom puis je passe aux dates.
Date naissance: j'inscris 32 août 1983, la date reste de couleur noire;
Lieu de naissance: j'inscris le lieu, la date reste en noir;
Date décès: Quand j'atteins ce champ, la date de naissance passe en rouge. J'écris pour le décès 30 février 1984, elle vire au rouge;
Lieu de décès: J'indique le lieu.
Je reviens sur les dates pour corriger. La date de naissance devient 31 août 1983, cette date reste en rouge, j'efface la date et j'indique à nouveau le 31, idem.
Je corrige la date de décès, et je mets le 28, la date repasse en noir.
Si j'efface la fiche et que je recommence, toujours le même problème avec la date de naissance qui reste inexorablement rouge. Il faut repartir de zéro (fermer la fiche) et recréer l'enfant pour avoir une fiche opérationnelle (date en noir pour la naissance si la date est correcte).
-2- Je fais la même manipulation que ci-dessus mais je n'inscris rien dans le lieu de naissance. La date de naissance qui n'est pas correcte, reste en noir.
C'est un mode de fonctionnement reproductible sur toutes les créations d'individus.
-3- Je crée la même chose avec des dates correctes, mais avec un décès avant la naissance, pas de message d'erreur au niveau de la fiche de saisie rapide. Celui-ci apparaît à l'enregistrement final de l'individu et après navigation vers lui.
Fiche identité
Résolu: Nous sommes bien revenus au patronyme en noir par défaut. Il passe à la bonne couleur après le choix du sexe et l'action Enregistrer.
La création d'un individu se fait avec un patronyme de couleur bleue avant même d'avoir choisi le sexe.
En réalité la couleur correspond à celle du dernier individu visité et à partir duquel est créée la nouvelle fiche.
Mise à jour
Ce point reste à vérifier.
Le lien ci-après donne la réponse faite à François sur les difficultés rencontrées lors des mises à jour:
http://www.ancestrologie.org/forum/index.php?topic=7611.0&sid=44bc11941a5465b26aae363b181db439
Il faudrait que Philippe parvienne à rétablir la situation qui amenait directement le message:
La version de votre base x.xxx est trop ancienne. Il vous faut la mettre à jour à l'occasion du démarrage d'Ancestrologie après la màj de l'application.
Les étapes intermédiaires (message d'erreur + Transaction...) sont de nature à créer des confusions.
C'est d'ailleurs d'un mal comparable que souffre la fonction Restaurer dans le menu Généalogies. Le recours à cette fonction conduit à un blocage d'Ancestrologie sans compter que les termes utilisés créent aussi la confusion entre Restauration et Restoration.
Sauvegarde/Restauration
Ce module accessible depuis le menu Généalogies ne fonctionne pas pour la partie sauvegarde.
Lieux
Résolu: Les remarques de Bob ont été corrigées.
Bob du Vaucluse a dit:
A partir de « index des lieux » soit directement soit par modification de « lieux préférés » on peut créer une nouvelle ville.
Le problème est que la liste des pays du menu déroulant n’est pas triée alphabétiquement (ce qui était le cas pour index lieu avant les modifications des lieux favoris)
Peut-on avoir cette modification là aussi
et André a répondu:
Et non, la baguette magique n'y peut rien parce qu'il ne s'agit pas d'une procédure intégrée à la base, mais de requêtes faites depuis le logiciel pour alimenter les listes déroulantes.
Il suffirait de remplacer la requête "select * from REF_PAYS" qui liste les pays dans l'ordre des codes, par "select * from REF_PAYS ORDER BY RPA_LIBELLE" qui les liste dans l'ordre des noms.
:arrow: La combinaison des deux màj me semble être une bonne chose pour la plus grande partie des utilisateurs. Le fichier est un peu lourd mais en définitive il fallait malgré tout d'une manière ou d'une autre charger la màj de l'application puis le cas échéant mais assez régulièrement la màj de la base.
Pour éviter les complications des trois màj, je verrais l'outil de màj complet en accès depuis le logiciel.
Les trois màj appli, base et appli+base téléchargeables depuis quelque part pour les accrocs des travaux manuels.
Il reste toutefois à vérifier le comportement de la màj complète dans les cas tordus: base inférieure à 3.57, base polluée notamment par des saisies de dates erronées, etc....
A méditer et à approfondir. Le principal point en suspens demeure le menu Sauvegarde/Restauration. Un peu à la fois et on va y arriver.
:arrow: D'autres améliorations en arrière plan ont été apportées avec les versions immédiatement avant:
- L'installation d'Ancestrologie sur un Ancestrologie existant prend en charge la sauvegarde de la base Ancestrologie.bdd présente (si nom inchangé);
- La désinstallation d'Ancestrologie maintient les documents personnels, même chose pour la base Ancestrologie.bdd ainsi que les autres bases contenues dans le répertoire \Database.
-
Je viens de faire l'essai de la mise à jour de base ET logiciel dans la foulée en utilisant maj_v695_b5016.exe
Un peu long à télécharger effectivement, mais une seule manoeuvre suffit, et je ne suis pas sûr que çà soit plus long en temps cumulé que par des mises à jour séparées.
Je suis sûr que çà conviendra mieux à des utilisateurs peu expériementés (et pas seulement). C'est à mon avis ce moyen qu'il faut mettre en évidence sur le site, même si on laisse la liberté à ceux qui suivent les évolutions au jour le jour, de continuer "manuellement".
Encore un +, merci à André et à tous ceux qui font avancer les choses.
-
Même point de vue que les précédants messages sur la MàJ "cumulée".
Des "détails" qui peuvent arrêter / perturber certains au moment des mises à jour : les fenêtres d'accueil et de fin et quelques bandeaux "bienvenue dans l'assistant de installation de MAJ_base", etc...
On croit que seul la base est MàJ...
Un autre détail à la 3ème fenêtre : un "vous" en trop à la 4° ligne ( ...vous devez vous être certain... )
:wink:
-
Bonsoir.
J'ai également trouvé le temps de chargement un peu long dû aux performances techniques de ma connexion mais ce n'est pas catastrophique.
Par contre il faudrait peut-être n'avoir qu'un seul système de mise à jour c'est à dire avoir toujours la même manoeuvre à effectuer qu'il y ait une maj logiciel+base ou une maj logiciel seul ou base seule... si c'est possible.
-
Et si on a plusieurs bases à mettre à jour? Je suppose qu'il faut utiliser la mise à jour de la base seule pour chacune d'entre elles.
-
La MAJ de la base ne s'applique qu'à la dernière base utilisée par Ancestrologie
-
Bonjour,
La MAJ de la base ne s'applique qu'à la dernière base utilisée par Ancestrologie
Rien de changé sur ce plan. La migration de la base s'applique toujours à la dernière base utilisée avant la fermeture du logiciel. Et la migration de la base seule sera toujours nécessaire, tout comme la nouvelle version du logiciel, car l'un peut évoluer sans l'autre.
Il doit être possible de modifier l'outil de migration complète pour qu'il n'exécute aucune opération sur la base si elle est à jour, ni écrase un logiciel plus récent que celui qu'elle contient. On n'aurait ainsi qu'un seul outil de migration. Mais il ferait plus de 8 Mo.
Si cet outil existait, utiliseriez-vous quand même les mises à jour séparées?
A+
André
-
Citation:
Les trois màj appli, base et appli+base téléchargeables depuis quelque part pour les accrocs des travaux manuels.
Je suis concerné. Mon côté collectionneur :lol:
J'ai fait les 2 types de màJ
Manu ou Auto
Pas de pbm
Avec l'exe tout en Un une petite minute
Avec les 2 màj successives il suffit d'être organisé.
Je pense que beaucoup n'ont peut-être pas assez de rigueur dans le classement de leurs différents éléments.
Merci encore, je vais utiliser quelque peu. @+++
-
Si cet outil existait, utiliseriez-vous quand même les mises à jour séparées?
Surement oui, dans la mesure ou je suis régulièrement les évolutions des versions béta. Mais on constate que la première intervention sur le forum est souvent faites par des utilisateurs peu expérimentés qui utilisent Ancestro depuis déjà quelques temps, et qui font une mise à jour pour la première fois et ne sont pas des accros du forum.
Dans ce cas, le téléchargement, même un peu long, n'est pas gênant, s'il apporte une simplification évidente.
Les mises à jour de Windows sont bien plus longues et nécessitent presque toujours un redémarrage... et on supporte.
-
Je reviens sur le tout en Un
Comme le dit Horemans il satisfera les gens pressés ou inexpérimentés.
De plus il soulagera le forum et ses bénévoles, évitant de reprendre pour la énième fois une sorte de tutoriel par posts interposés (bien que le sujet soit déjà traité, mais c'est dur de chercher... "y aura bien un type sympa qui va se décarcasser").
Donc ce sera plus de temps pour commenter les nouvelles fonctionnalités.
-
Bonjour André,
Bonjour,La MAJ de la base ne s'applique qu'à la dernière base utilisée par Ancestrologie
Rien de changé sur ce plan. La migration de la base s'applique toujours à la dernière base utilisée avant la fermeture du logiciel. Et la migration de la base seule sera toujours nécessaire, tout comme la nouvelle version du logiciel, car l'un peut évoluer sans l'autre.
Il doit être possible de modifier l'outil de migration complète pour qu'il n'exécute aucune opération sur la base si elle est à jour, ni écrase un logiciel plus récent que celui qu'elle contient. On n'aurait ainsi qu'un seul outil de migration. Mais il ferait plus de 8 Mo.
Si cet outil existait, utiliseriez-vous quand même les mises à jour séparées?
:arrow: J'ai la manie de charger les màj puis de les mettre en oeuvre dans un deuxième temps. Je m'écarte ainsi de l'utilisation standard. Mais les essais et tests sont nombreux et cette disposition simplifie la mise en oeuvre des màj ainsi que les éventuels retours en arrière.
:arrow: J'ai utilisé l'outil de màj complet sur Ancestrologie v690 et une base b5.015. Tout s'est déroulé correctement.
J'ai sélectionné une autre base qui a été ouverte sans le moindre problème et "sans message de base trop ancienne", j'ai stoppé Ancestrologie et lancé à nouveau la màj complète. Tout s'est déroulé correctement. Je regrette simplement l'absence de message pour attirer l'attention sur la base un peu démodée.
:arrow: Si un jour cette méthode devait devenir la màj via l'application, il faudrait revoir la fenêtre de màj.
-1- Supprimer l'accès à la Bêta;
-2- Ajouter un test complémentaire pour faire une màj de la base lorsque l'appli est déjà en ordre. Ce point est surtout utile pour ceux qui travaillent avec plusieurs bases.
-
Et puis on pourrait aussi continuer à monter une usine à gaz en faisant la sauvegarde automatique de la base mise à jour... :wink:
-
sauvegarde automatique de la base mise à jour... :idea:
Puisque la sauvegarde est une recommandation de bon sens le faire avec l'outil en la datant devient logique.
Mais jusqu'où iront-ils :?:
-
Mais jusqu'où iront-ils :?:
J'usqu'à faire un maximum de généalogie pour un minimum d'informatique. Si la complexité est concentrée dans un outil d'une grande simplicité d'utilisation, peu importe si la réalisation de l'outil est complexe, c'est l'affaire du programmeur... s'il le souhaite... et c'est le contraire d'une "usine à gaz". :wink:
-
M... et c'est le contraire d'une "usine à gaz". :wink:
Même pas! qu'est-ce que vous avez contre les usines à gaz? Vous vous chauffez à quoi? Et puis dans une usine à gaz ce qui importe c'est ce qui entre et ce qui sort ,l'usine on s'en fiche si elle donne du bon gaz pour pas cher. Tout bien réfléchi le PC qui est à 30 cm devant vous en ce moment même (Et Oui en plus je suis voyant je vous vois à l'instant précis où vous lisez ce mot, je vous vois dis-je, devant votre microordinateur (et je pense que c'est un PC!!, et qu'il y a "Ancestro forums" d'écrit sur votre écran (qui est allumé!)), donc le PC qui est sous votre regard est aussi une usine à gaz et poutant vous en accommodez.
-
Encore plus fort que madame Irma !!
:(https://forum.ancestrologie.org/proxy.php?request=http%3A%2F%2Fsmileys.sur-la-toile.com%2Frepository%2FGrands_Smileys%2F3d-clavier-lunettes.gif&hash=f07d0b7ad6c15c5fd6b124ea7ab0c1c74cebdf05)
(https://forum.ancestrologie.org/proxy.php?request=http%3A%2F%2Fsmileys.sur-la-toile.com%2Frepository%2FGrands_Smileys%2F3d-casquette-applaudir.gif&hash=db3f349b4a1556e013dc32052cd153df1e93560d)
-
Bonjour,
J'ai essayé de tenir compte de vos commentaires pour ajouter quelques tuyaux à la migration complète, en espérant qu'il n'y aura pas trop de fuites (à grandes enjambées).
Le titre a été modifié pour indiquer que cette mise à jour concerne la base ET le logiciel.
Ancestrologie.exe est copié, sauf si cette version ou une plus récente est déjà installée.
Firebird embedded est copié s'il est utilisé (=présence de gds32.dll dans le répertoire d'ancestrologie).
Si l'exe précédent était à une version <V550 (versions qui n'enregistraient pas la version de la base dans la BDR), la migration de la base ne s'exécute pas, et l'utilisateur est prévenu qu'il devra relancer la migration, après avoir exécuté une fois le logiciel.
Si la base est à une version <3.57, la migration de la base ne s'exécute pas, et l'utilisateur est informé qu'il devra faire le transfert des dossiers de sa base dans une base vide, par la fonction de transfert ou Mutancestre.
Les documents et les tables de références sont mis à jour en fonction de la version de la base (tous mis à jour si la version de la base est inconnue)
Si la base est déjà à la version ou supérieure, elle n'est pas modifiée.
Si elle est mise à jour et si la base est locale (çà ne marche pas en réseau), la base est sauvegardée au même endroit sous le même nom auquel est ajouté la date et l'heure. Ceci explique un délais de démarrage plus important. Et assurez vous d'avoir assez de place sur le disque... Un message donne le nom de la sauvegarde.
Si vous voulez essayer, le fichier a été mis à jour sur mon site, avec le lien dans le premier message de ce fil.
Dites moi si çà fuit.
André
-
mpl75 a écrit:
M... et c'est le contraire d'une "usine à gaz".
Désolé c'est pas de moi :roll:
J'ai téléchargé et je vais tester. Merci.
-
J'ai fait un retour arrière enrevenant à une version plus ancienne pour pouvoir tester.
Téléchargement : 4mn
Après avoir lancé Ancestro pour réinitialiser la base de registre avec cette version plus ancienne, j'ai lancé Maj_v695_b5016.
La sauvegarde de début m'a semblé rapide (mais correcte).
L'optimisation m'a semblée relativement longue (environ 6mn, 6900 individus, 30 Mo)
Mais à part le double clic sur le programme, je n'ai eu aucune intervention. c'est facile à utiliser.
Par contre, je n'ai pas eu (ou pas vu) les messages d'avertissement quand j'ai lancé la mise à jour sur une version de programme et de base déjà à niveau. J'ai cliqué sur "je comprends/suivants, 2 fois/ terminé, mais aucun avertissement. Je n'ai pas non plus trouvé de fichier log
-
Par contre, je n'ai pas eu (ou pas vu) les messages d'avertissement quand j'ai lancé la mise à jour sur une version de programme et de base déjà à niveau. J'ai cliqué sur "je comprends/suivants, 2 fois/ terminé, mais aucun avertissement.
Idem pour moi, Nickel
-
Bonsoir,
Rien n'a changé côté optimisation.
Il n'y a pas de message particulier si la base est déjà à jour, la seule différence c'est que c'est plus rapide et qu'il n'y a pas le message de sauvegarde. Est-ce vraiment nécessaire d'en ajouter un pour dire "Votre base est déjà à jour"? De toute façon , elle l'est à la fin.
Le fichier modifbase.log se trouve dans le répertoire ancestrologie. Mais il n'est effectivement généré que s'il y a mise à jour de la base.
Bonne nuit
André
-
Le fichier modifbase.log se trouve dans le répertoire ancestrologie. Mais il n'est effectivement généré que s'il y a mise à jour de la base.
Aurait-il été effacer quand j'ai lancé une deuxième fois pour voir ce qui pouvait se dire sur des éléments déjà à niveau, il n'y en a pas trace chez moi.
Je suis d'accord qu'il n'y a pas besoin de message pour signaler que le fichier ou la base sont à jour, c'était un simple constat.
La durée de l'optimisation un peu longue était du à un ralentissement de ma machine pour d'autres raisons. Donc tout est parfait pour moi.
-
Bonjour,
Aurait-il été effacer quand j'ai lancé une deuxième fois pour voir ce qui pouvait se dire sur des éléments déjà à niveau, il n'y en a pas trace chez moi.
C'est exact. L'ancien fichier modifbase.log est supprimé au début de la migration, pour ne pas gêner la création du nouveau ou créer une confusion entre les 2 migrations.
Bon WE
André
-
Je suis en V695 (bêta) b5.016.
Lorsque je mets une date à une profession, on peut la modifier mais pas la supprimer. Pour supprimer la date, la seule chose que j'ai trouvée c'est de supprimer l'événement et de le recréer.
-
Je suis en V695 (bêta) b5.016.
Lorsque je mets une date à une profession, on peut la modifier mais pas la supprimer. Pour supprimer la date, la seule chose que j'ai trouvée c'est de supprimer l'événement et de le recréer.
Je confirme : Ayant entré une profession avec une date j'ai eu le même pbm pour la supprimer
-
Ce n'est ni particulier à la profession, ni à l'événement individuel. L'anomalie existe pour toutes les dates, événement individuel, familial, domicile et saisie rapide.
Dans un de ces champs où existe une date, supprimez-là par la touche d'effacement arrière depuis la fin. Quand vous quittez le champ, le premier caractère de la date revient, dans la couleur où il était avant que vous l'ayez effacé.
A+
André
-
Tout à fait.
Il est donc impossible de vider le champ en conservant l'évènement
-
Bonsoir,
Ancestrologie dispose actuellement d'un système d'alertes sur anomalies concernant les âges des individus (âge au mariage, à la naissance d'un enfant etc...). Ce système nécessite que l'on visualise la fiche identité pour apercevoir une fenêtre bleue ou un panneau de sens interdit. Mais il ne permet pas de retrouver rapidement les anomalies existantes, en particulier à la suite d'une importation gedcom.
Afin de pouvoir générer une liste de ces anomalies présentes dans un dossier, j'ai ajouté à la base une procédure PROC_DATES_INCOHERENTES.
Cette procédure peut être exécutée depuis le BOA. Malheureusement, comme les 12 paramètres de contrôles des âges (ceux qui sont accessibles depuis l'onglet "Contrôle de cohérence" des "Préférences générales") sont mémorisés dans la base de registre, ils ne sont pas accessibles depuis la base de données. Ils doivent donc être fournis comme paramètres d'entrée de la procédure, ce qui fait 13 paramètres avec le n° de dossier :(
Il faudrait donc que ce soit le logiciel qui les transmette.
En attendant que Philippe nous propose cette liste sous forme de document imprimable (çà me semblerait plus pratique pour conserver la liste sous les yeux, pendant que l'on navigue entre les fiches pour les contrôler, à moins qu'il nous propose une fenêtre séparée comme l'Histoire?), j'ai développé un petit utilitaire qui fonctionne à l'image de Mutancestre. Vous pouvez en télécharger le fichier d'installation ICI (http://andre.langlet.free.fr/ancestro/InstIncoherences.exe)ou en bas de mon premier message de cette discution (les autres liens ont aussi été mis à jour). L'exécution de ce fichier installe un fichier Incohérences.exe dans le répertoire Ancestrologie, et le raccourci de lancement dans le groupe de démarrage d'Ancestrologie.
Ceux qui utilisent Firebird serveur ont l'avantage de pouvoir laisser la fenêtre ouverte en même temps que celle d'Ancestrologie.
Pour la mise à jour de la base, je vous conseille d'utiliser la migration complète. Elle contient un nouveau fichier ancestrologie.exe corrigé par Philippe où l'anomalie sur la suppression de la date n'existe plus. Mais comme cet exécutable affiche toujours le version V695, il n'écrasera pas le fichier en V695 précédent s'il est présent. Il faut donc, avant d'exécuter l'outil de migration complète, supprimer le fichier ancestrologie.exe existant dans le répertoire ancestrologie (ou le remplacer par un plus ancien).
Le fichier pour la migration sans le logiciel a été restructuré comme celui de migration complète. Il sauvegarde également la base avant de la mettre à jour. Petit changement dans le nom du fichier de sauvegarde: la date ajoutée au nom est dans le format "aammjj-hhmm". Cà permet un classement alphabétique identique au classement chronologique des fichiers.
Bons tests.
André
-
... j'ai développé un petit utilitaire ....
Oui mais un grand pas pour l'Ancestrologitude.
A ce propos quels sont les premiers mots d'Amstrong après avoir posé le pied sur la lune?
Merci André, cela fonctionne à merveille. J'ai remarqué en testant que si on se connecte à une base avec plusieurs dossiers il va automatiquement chercher le premier dossier de cette base. Est-ce voulu ?
-
En attendant que Philippe nous propose cette liste sous forme de document imprimable
Cette liste pourrait se substituer à celle obtenue par
Individus/Les Listes/ Liste des erreurs sur les événements individuels ...
qui renvoie bizarrement "Bravo il n'ya pas de doublons" qui flatte notre ego mais ne sert à rien (Alors qu'il y a une vrai fonction "Recherche de doublons"
Il suffirait de remplacer "Liste des erreurs sur les événements individuels ..." par "Liste des incohérences" et de pouvoir la stocker dans un fichier
-
Bonsoir André,
J'ai testé ton petit utilitaire "Incohérences"... Super, il m'a déjà permis de détecter des erreurs de date.
Toutefois j'ai constaté un petit bogue.
Ma base comporte 2 dossiers : le 1 et le 3
Dans les incohérences du dossier n°1, à la rubriques "Femmes(s) -il y a d'ailleurs un "s" de trop à femme- ayant eu deux enfants en moins de 300 jours", les femmes des 2 dossiers sont mélangées.
Même problême quand on cherche les incohérence du dossier n°3 (à la même rubrique, les femmes du dossier n°1 s'y retrouvent aussi).
En tous cas, BRAVO ! ! !
-
Bonsoir,
Dans les incohérences du dossier n°1, à la rubriques "Femmes(s) -il y a d'ailleurs un "s" de trop à femme- ayant eu deux enfants en moins de 300 jours", les femmes des 2 dossiers sont mélangées.
Bien vu, je vois que tout le monde ne dort pas. :lol:
Très pratique le copier/coller, c'est comme celà qu'on retrouve 4 fois le "s" en trop à femme. C'est réparé ainsi que l'absence de la sélection du dossier sur la dernière recherche, mais je n'ai pas modifié l'indice de la base. Il faut donc repartir de l'ancienne base pour faire la migration.
Les fichiers sont en cours de transfert, ils seront sur mon site dans 10mn.
Bonne nuit
André
PS pour Françoise: la recherche est déclenchée par la modification du champ dossier. Comme à la connexion de la base, ce champ affiche le premier dossier de la base...
-
Bonjour André,
Je ne dormais pas mais mes pensées étaient ailleurs.
J'ai découvert ce nouvel utilitaire et j'ai regardé ce que cela donnait.
C'est un peu du type "doublons", j'ai pris une claque. Il faudrait que tu donnes deux uo trois recettes car il y a des situations qui m'échappent.
:arrow: Dans un dossier j'ai une certaine Barbe Lesaffre prise en infraction pour avoir eu deux enfants sur une période trop courte. Les dates de naissance des bambins sont respectivement:
13 mars 1681;
7 juillet 1682;
vers 1685;
calculée 1687;
avant 1694;
22 février 1695.
Je pense que les approximations sont de nature à introduire des erreurs sur les conclusions et cela ne me perturbe pas outre mesure. Faut-il considérer les anomalies comme des anomalies potentielles?
:arrow: J'ai fait l'essai sur la base ancienne revenue de chez toi 1.043 -> 5.015 et tout va bien, aussi bien pour le dossier transférer à l'aide de Mutancestre 2.03, que pour l'import gedcom. Je vais le même essai sur une base avec laquelle j'avais fait le même exercice. Sur les deux dossiers j'ai Erreur Base: Impossible de se connecter à la base. Cette base s'ouvre sans problème avec Ancestrologie.
:arrow: J'ai fait l'essai sur une base 5.001 migrée elle aussi en b5.017 et c'est ok.
J'ai ainsi plusieurs bases sur lesquelles j'ai des blocages et il semble qu'à chaque fois c'était à la suite de l'utilisation d'une base vide 5.015. Vois-tu une opération à réaliser pour clarifier la situation?
:arrow: Un petit plus serait de mettre en caractères gras les titres des contrôles effectués.
N'est-il pas possible de mettre un clic droit sur la fenêtre des résultats pour recopier vers autre chose pour conserver une trace des anomalies.
-
Bonjour,
Encore des évolutions sans changer la version de la base.
La procédure PROC_DATES_INCOHERENTES a été complètée.
Le champ TITRE a été ajouté aux variables de sortie. Ce champ passe à 1 pour signaler les lignes de titre. Le but est de pouvoir mettre les titres en gras par exemple, dans un document. Pour répondre à Christian, je ne sais pas le faire dans le petit utilitaire, mais celà sera possible dans un état (document) d'Ancestrologie. En attendant, il y a tout de même une ligne vide avant chaque titre, et l'utilitaire avec FB serveur en permettant de visualiser la liste tout en consultant les individus dans Ancestrologie, permet au moins en partie, de se dispenser de l'exportation de la liste.
Deux tests de cohérence ont été ajoutés:
Individu(s) ayant un événement avant la naissance.
Individu(s) ayant un événement après le décès, l'inhumation ou l'espérance de vie.
Les événements individuels et familiaux sont pris en compte.
Dans le dernier test, une inhumation avant le décès est une anomalie mais pas si elle a lieu après. Si elle existe c'est l'inhumation qui est utilisée comme date limite. S'il n'y a ni inhumation, ni décès, c'est la longévité qui donne la date limite.
Explications permettant de comprendre pourquoi un enfant né "avant 1694" et un autre né le "22 février 1695" sont signalés comme nés en moins de 300 jours:
Le calcul ne prend pas en compte les mots clés utilisés dans les dates, il n'utilise que la première date mémorisée dans des champs de l'événement (mois, année et date si complète). Si la date n'est pas complète (absence du jour), la date prise en compte pour le calcul d'écart est:
le 15 du mois si le mois existe,
le 15 du mois de juin (environ le milieu de l'année) si seule l'année est connue.
"avant 1694" est donc interprêté comme le 15 juin 1694 qui est moins de 300 jours avant le "22 février 1695".
De même un individu décédé le 30 septembre 1900 et inhumé en 1900 est une anomalie, mais pas s'il est décédé en février 1900.
La prise en compte des mots clefs demanderait l'analyse de toutes les dates telles qu'elles sont saisies, ce qui prendrait beaucoup plus de temps. Et il y a 15 tests à faire :(
A+
André
-
Bonjour André,
Merci pour les explications.
:arrow: Pour les dates approximatives, ton explication permet de calculer 252 jours au lieu des 300. C'est bien ce qui était indiqué.
:arrow: Pour les titres en gras, c'est secondaire et de fait il y a une ligne intercalaire.
:arrow: Pour ce qui est de certaines bases qui refusent l'ouverture, je poursuis les investigations.
-
Un contrôle supplémentaire possible : 2 enfants nés à plus de 25 ans d'écart dans la même famille (FAM) il manque peut-être une épouse.
J'ai eu le cas...
Un export ou impression par clic droit... sera effectivement le bienvenu.
Encore un petit utilitaire pas si petit, mais qui manquait.
Merci DD
-
Un contrôle supplémentaire possible : 2 enfants nés à plus de 25 ans d'écart dans la même famille (FAM) il manque peut-être une épouse.
Dans ce cas, les contrôles sur l'âge de la mère à la naissance ne détecteraient-il pas l'anomalie?
A+
André
-
Il y a largement la place : mère à 43 ans (moins de 45 ans) qui a eu un enfant à 18 ans (après 16 ans). Avec tes dates limites la maman peut en avoir 4 autres. Il est vrai que ce n'est pas un contrôle qui détectera beaucoup de cas.
Autres contrôles possibles :
:arrow: Date dans le futur (lAncestro le dit à la saisie, mais accepte l'enregistrement)
:arrow: Naissance plus d'un an après décès du père
:arrow: La mère doit être en vie à la naissance
-
Très bien joué ce nouvel outil...
Trop bien? ::) ;)
Je m'explique...
Monsieur A se marie le 11 mars 1828.
J'estime qu'il est né au moins 12 avant, en utilisant les contrôles de cohérences d'ancestro
Je rentre donc une estimation de sa naissance : "avant 1816"
Ancestrologie ne me pose aucun problème de "sens interdit", même si il calcule qu'au mariage Monsieur A a 11 ans et 8 mois
Je lance incohérences... il apparait dans la liste "marié avant l'age de 12 ans" avec un écart de 11.7 ans.
Au passage, je remarque que si je donne l'estimation "avant mars 1816", incohérence ne repère plus Monsieur A... ;)
Par là, je veux dire qu'il pourrait être interessant d'avoir le même point de repère incohérences et Ancestrologie...
-
Bonjour,
Très bien joué ce nouvel outil...
Trop bien? ::) ;)
Par là, je veux dire qu'il pourrait être interessant d'avoir le même point de repère incohérences et Ancestrologie...
A ce jour, l'utilitaire de recherche d'incohérence est une pièce rapportée. J'imagine que André a tout prévu et notamment la reprise des consignes fixées dans Ancestrologie en termes d'incohérences lorsque cette fonctionnalité sera intégrée à Ancestrologie.
-
Merci André
l'utilitaire est un vrai plus
Car j'était oubligé de faire des exports GEDCOM et de passer visuged et Généalogica pour avoir ce genre de liste
Un pas de plus vers l'intégration des fonctions
-
Bonjour Christophe et à tous,
Ton raisonnement de "puriste" est exact.
Tout est question de temps, d'optimisme, de moyens et de besoins.
-Par temps, je veux parler de la durée du contrôle. Une requête comparant des données existantes dans la même table est beaucoup plus rapide que s'il faut aller chercher ces données dans différentes tables pour les analyser avant d'en ressortir un résultat. Ainsi pour faire apparaître le "sens interdit", je suppose que seules sont prises en compte les différences d'années. L'affichage de l'âge lors d'un événement utilise une procédure qui ne prend en compte que la première des dates dans la période saisie (entre xxxx et yyyy), il en faut bien une sans celà il faudrait fournir une fenêtre d'âge. Et si la date n'est pas complète (sans le jour), c'est le milieu de la période précisée qui est pris en compte (le 15 du mois s'il est précisé, sinon le milieu de l'année).
-C'est là que l'on pressent la notion d'optimisme. Lorsque l'on recherche si une mère est trop jeune à la naissance de son enfant, si l'on est optimiste, en cas de date incomplète on considèrera le 1 du mois ou le 1 janvier de l'année pour sa naissance, et de 28 au 31 (selon le mois) ou le 31 décembre de l'année pour la naissance de l'enfant. En comparaison pessimiste, ce sera l'inverse.
-Pour les moyens, il y a ceux dont on dispose pour obtenir un résultat, la structure de la base, la précision des informations fournies, et ceux que l'on veut ou peut mettre pour y arriver (l'énergie et le temps de programmer).
-Par besoins, j'entend la précison que l'on estime nécessaire, en relation avec l'importance de cette fonction et des conséquences de ses résultats.
J'ai actuellement revu cette fonction pour y ajouter:
-le contrôle de l'écart entre la première et la dernière naissance d'enfants d'une femme, en prenant comme valeur maxi âge maxi - âge min pour avoir un enfant. J'ai en effet constaté que le contrôle sur l'âge maxi ne peut pas être efficace si la la date de naissance de la mère est inconnu. Cà m'a permis de détecter que dans une famille, les 11 enfants nés en 45 ans, ne pouvaient avoir la même mère.
-les naissances plus de 270 jours après le décès du père.
-les naissances après le décès de la mère.
Je revois cette procédure pour adopter une vue plus optimiste lors de la détection des erreurs (choisir les dates qui minimisent les erreurs). Mais elle fait déjà 700 lignes...
Si on veut faire mieux, c'est à la structure de la base qu'il faudrait s'attaquer, en particulier en mémorisant séparément pour chaque événement, les types des mots-clés utilisés.
A+
André
-
Observation: Incohérences me donnait un écart de -171 ans au mariage pour une naissance Vers 1700 et un mariage le 22/11/1728.
Cette anomalie observée dans plusieurs cas.
La raison: j'ai l'habitude de commencer une phrase ou un élément de phrase par une majuscule et avais donc saisi la date de naissance Vers 1700; une fois saisie vers 1700 l'anomalie disparait.
Conclusion Ancestrologie devrait refuser Vers ou le transformer en vers (il me semble d'ailleurs qu'il le faisait?)
-
Conclusion Ancestrologie devrait refuser Vers ou le transformer en vers (il me semble d'ailleurs qu'il le faisait?)
Heureusement, tes Vers avec majuscule, sont moins dangereux que les virus ;)
-
Ton raisonnement de "puriste" est exact.
Tout est question de temps, d'optimisme, de moyens et de besoins.
;)
-
La raison: j'ai l'habitude de commencer une phrase ou un élément de phrase par une majuscule et avais donc saisi la date de naissance Vers 1700; une fois saisie vers 1700 l'anomalie disparait.
Conclusion Ancestrologie devrait refuser Vers ou le transformer en vers (il me semble d'ailleurs qu'il le faisait?)
Tout dépend du "mot clef utilisé dans la saisie des dates" figurant pour le type "Vers". Quand Forme n'est pas 'NON' (donc LIT ou NUM), le mot clef de type "Vers" sera remplacé par:
le mot clef figurant en face de utilsation='Y' (date sans le jour), normalement "vers"
le mot clef figurant en face de utilisation='D' (date avec le jour), normalement "vers le"
Ton exemple doit dater de quelques mois, car avant la version 5.000, pour être reconnu, et que la reconnaissance de la date fonctionne, les mots clés utilisés devaient être rigoureusement identiques à ceux figurant dans la liste. Donc "Vers" n'y figurant pas n'était pas reconnu.
Depuis la version b5.000, la reconnaissance fonctionne indépendamment de la casse et des accents. Donc plus de problème, on pourrait même supprimer de la liste des mots clés certaines variantes mises là pour reconnaître des mots mal orthographiés.
A+
André
-
J'espère que c'est la dernière fois que je réédite cette version b5.017.
La procédure PROC_DATES_INCOHERENTES fait maintenant 800 lignes et effectue 17 types de contrôles.
Comme dit précédemment cette version intègre maintenant:
-le contrôle de l'écart entre la première et la dernière naissance d'enfants d'une femme, en prenant comme valeur maxi âge maxi - âge min pour avoir un enfant.
-les naissances plus de 270 jours après le décès du père.
-les naissances après le décès de la mère.
Tous les contrôles ont été revus pour que lorsque les dates comportent une incertitude (sur le mois ou l'année), la solution la plus optimiste, celle qui risque le moins de déclarer l'anomalie, soit adoptée.
Il ne devrait donc plus y avoir de fausses anomalies.
Bons tests
André
-
Bonjour,
Merci pour toutes ces avancées.
Juste une petite demande :
Les liens pour télécharger pourraient-ils être mis en évidence un peu plus dans les textes (expression en gras par exemple) ou page dédiée qui regroupe tout. Juste pour faciliter l'accès...Merci encore.
-
bonsoir,
je viens de remarquer un petit bug qu'il n'y avait pas avant (depuis quand mistere)
je suis en v695 b5.016
pour tous les evenements d'un individu:
je saisie une date ou par erreur autre chose du text (c ce que j'ai fait)
je l'efface a l'aide de suppr ou retour arriere
je passe a un autre champ
et la le texte supprimé revient
pas moyen de vider le champ date, obliger de supprimer l'evenement!
quelqu'un a t'il remarqué le meme bug?
-
pas moyen de vider le champ date, obliger de supprimer l'evenement!
quelqu'un a t'il remarqué le meme bug?
Oui, réponse #25 de ce fil. C'est réparé dans le fichier ancestrologie.exe qui fait partie de la migration complète. Mais pour l'appliquer, comme exécutable et base n'ont pas changé d'indice, il y a quelques manipulations à faire. (décrites dans un message qui suit la #25).
A+
André
-
Encore quelques lignes à ajouter à PROC_DATES_INCOHERENTES mais rien ne presse :
Dans Individus ayant un événement après le décès.... et Crémation à ajouter (tag CREMA)
J'ai pu détecter des erreur pas évidentes à trouver, surtout avec des dates approx comme "entre xxxx et xxxxx"
Voilà un outil qui est... un outil
-
tag CREM je ne l'avais pas encore vu celui là. :evil:
Les tests mettant en jeu la fin de vie sont nettement plus complexes que ceux sur la naissance.
A+
André