Sujet: Base (b5.012) b5.014 à tester.[terminé]

[DDdeBerdeux]

Bonsoir,

Avant de prendre quelques jours de vacances, j'ai pensé à ceux qui restent

Voici une mise à jour de la base en version 5.012 à télécharger ICI et la base vide accompagnée de la liste complète des modifications LA .

Les modifications depuis la versions b5.011:

Création PROC_TEMOINS_DE_IND et PROC_IND_EST_TEMOIN et ajout à PROC_NAVIGATION des témoins de l'individu ainsi que ceux dont l'individu est témoin.

Champ HI_DICORIGINE porté à 8 caractères (pour identifier par son code INSEE un dictionnaire lié à une ville). Création index sur HI_DICORIGINE.

Suppression PROC_ACTES_AFFECT_IMAGE, PROC_DER_PHOTO inutilisées.

Suppression de la modification de MULTIMEDIA dans PROC_ACTES_RAZ, PROC_DEL_CASCADE_INDIVIDU.

Optimisation de PROC_PREP_VILLE_RAYON et création index sur latitude et longitude de REF_CP_VILLE. Recherche des villes à une distance limite beaucoup plus rapide.

Contrôle de la création d'événements naissance ou décès en double par les triggers de la table EVENEMENTS_IND. Evénements en doubles remplacés par un événement Divers avec en titre le nom de l'événement, lors de l'importation ou de la création.

Mise à jour de Firebird embedded en version 2.0.1.

Vous ne pourrez je pense constater l'influence des modifications concernant les témoins et l'histoire que lorsque Philippe aura modifié le logiciel pour en profiter.

L'accélération de la PROC_PREP_VILLE_RAYON devrait être visible lors de l'affichage des villes voisines depuis les lieux favoris, surtout si vous avez un PC un peu lent.

Le transfert en événement divers d'une naissance ou décès en double peut être mis en évidence à cause d'une anomalie actuelle de l'exécutable qui permet d'activer les boutons N et D alors que ces événements sont déjà créés. Mais la vraie raison de cette modification, c'est que j'ai constaté ces événements en doubles dans des gedcom "étrangers". Ancestrologie ne les bloquent pas à l'importation, mais ils provoquent des anomalies de fonctionnement assez graves.

Les autres procédures supprimées ou modifiées sont des "scories" de probablement une ancienne version d'ancestrologie. Elles ne correspondent plus du tout à la structure actuelle. Mais comme je ne suis pas sûr que le logiciel ne les appelle plus, je vous en donne les noms pour que vous puissiez me signaler leur présence sur un éventuel message d'erreur.

Bons tests.

André

Réédition du 24/02/2007: passage en b5.013

Réédition du 27/02/2007: passage en b5.014

[Bob du Vaucluse]

Bonjour



Quel est l'interet de Firebird 201 qui est encore en beta



bonnes Vacances

[DDdeBerdeux]

Quel est l'interet de Firebird 201 qui est encore en beta

Voir la liste des bugs rectifiés http://www.firebirdsql.org/download/prerelease/rlsnotes201rc1_0201_02.pdf

Je n'est pas vu de correctif qui pourrait avoir de conséquences sur le fonctionnement d'ancestrologie, quoique l'un de ces bugs (CORE-1064) est peut-être à l'origine du problème de jeu de caractères rencontré par feiv5354 http://www.ancestrologie.org/forum/index.php?topic=7497.0

Pour les développeurs la levée du verrou interdisant la modification d'une procédure utilisée depuis le début de la session est particulièrement intéressante. Ce verrou introduit par la première version 2.0 était "pénible" lors de la mise au point d'une procédure.

A+

André

[Bob du Vaucluse]

Ok

Merci



et pas de travail pendant les vacances

[DDdeBerdeux]

En vacances, mais b5.013 quand même...

Les modifications concernent la possibilité de saisir des dates entre les années 1 et 100 de notre ère. Est-ce depuis le passage à Firebird 2.0 (il me semble que çà marchait correctement sous FB 1.5), les années avant 100 étaient interprêtées comme après 2000.

Pour les années avant JC (année négatives), seuls le mois et l'année sont retenues pour les événements individuels et familiaux.

Pour les événements historiques, les dates avant JC sont ignorées, et ces événements paraissent en début de liste, dans l'ordre de leur saisie. Il sera difficile de faire autrement, car la table histoire n'a qu'un champ de type Date, et FB ignore les dates avant JC...

Les liens du premier message ont été mis à jour.

Si vous pouviez vérifier qu'il n'y a pas de conséquences ailleurs...

A+

André

[Facon]

Bonjour André,

J'ai fait quelques exercices avec la base b5.013 en constituant une famille virtuelle.

Sur ce poste je suis en V680 b5.013



Constats:

 - Contrairement à ce que tu as indiqué, les jours sont bien affichés dans les événements se déroulant dans les années négatives;

 - Les événements N et D sont classés dans le désordre si N est <0 et D >0;

 - L'âge au décès n'est pas indiqué si N et D <0 ou N <0 et D >0;

 - L'affichage dans les fenêtres Conjoint(s) et Enfant(s) ne prend pas en compte les dates <0;

 - Il n'y a pas de message d'erreur lorsqu'il y a incohérence avec l'espérance de vie, âge mini pour se marier, ... lorsque N est <0 et N et D <0;

 - Les individus avec N <0 n'apparaissent pas dans les anniversaires;

 - Documents:

 -1- Dans de nombreux documents les individus avecN <0 n'apparaissent pas parceque l'êchelle commence à zéro (longévité, recensement, ..);

 -2- Dans la fiche individuelle, l'événement décès et positionné avant la naissance si N seul est <0;

 -3- Le document Age à la première union est lui aussi dérouté par les dates <0;



Je vais encore continuer un peu pour essayer de voir les choses principales. (transfert de dossier, etc..)

[DDdeBerdeux]

Bonsoir,

- Contrairement à ce que tu as indiqué, les jours sont bien affichés dans les événements se déroulant dans les années négatives;

Bizarre, j'ai créé une nouvelle fiche pour un individu né le 19/12/-123 et décédé le 15/12/-100. Après enregistrement, je retrouve décembre -123 et décembre -100 (précision qui me paraît bien suffisante pour nos connaissances de ces dates).

Et par la suite, il y a bien des erreurs "informatiques" du type "erreur de conversion" (sans conséquences sur les données enregistrées). Tous les calculs qui se font sur les dates sont en effet rendus impossibles car Firebird est incapable de travailler sur des dates avJC. Si on voulait que ce soit possible, il faudrait refaire tout le logiciel pour enregistrer séparément jour, mois et année de chaque événement, et remplacer toutes les routines qui utilisent des calculs sur les dates, par des calculs beaucoup plus complexes utilisant les 3 éléments séparés. Sans oublier d'autres anomalies comme le numéro SOSA qui ne permet plus de différentier la mère du père à partir de la génération 49 (vers 500).

Ancestrologie est un logiciel de généalogie, pas d'histoire. Je ne pense pas qu'il faille dépenser plus d'énergie pour l'améliorer dans ce sens.

Des essais de fonctionnement entre l'an 1 et 2050 me satisfont amplement.

A+

André

[Ancestrologie]

Tiens je viens de revoir le film Da Vinci code



eux y remontent à Jésus, je vais leur proposer Ancestro



Pourquoi vouloir galerer avec des dates négatives, qui arrive a remonter meme avec des dates a 2 chiffres ?



et puis pourquoi galerer comme ca

car on ne dis pas -150, mais 150 avant JC, et en allant plus loin on risque de se retrouver un ancetre cromagnon  



donc le pb est résolu

[Facon]

Bonsoir,

Je reconnais que la remontée aussi loin dans le temps peut sembler être une vue de l'esprit mais la question était posée.

Je regrette de ne pas avoir déclaré la question qui me démangeait, à savoir comment écrire la date négative: - 12 décembre 22 ou 12 décembre -22 ou encore autre chose comme relevé par Philippe.

Dans les quelques essais effectués j'ai retenu la première possibilité qui semblait fonctionner presque correctement. J'admets volontiers que nous pouvons avoir des doutes sur l'utilisation de dates aussi lointaines avec la précision de la journée.



Comme le problème est réputé résolu, je suggère que nous utilisions cette accalmie pour avancer dans la résolution des anomalies persistantes: Sauvegarde/Restauration, la création d'un individu dans la fiche individu pour lequel le patronyme est de couleur bleue (H ou F) avant validation, traitement meilleur des màj, etc... et quelques questions nouvelles: affichages des conjoints au lieu du seul dernier conjoint dans le répertoire, ... et un beau jour la progression vers la conformité au gedcom.

Je pense que ces propositions trouveront plus de preneurs que la résolution du traitement des dates négatives par la refonte complète du logiciel.

[BLefebvre]

Bonsoir,



Comme le problème est réputé résolu, je suggère que nous utilisions cette accalmie pour avancer dans la résolution des anomalies persistantes: Sauvegarde/Restauration, la création d'un individu dans la fiche individu pour lequel le patronyme est de couleur bleue (H ou F) avant validation, traitement meilleur des màj, etc... et quelques questions nouvelles: affichages des conjoints au lieu du seul dernier conjoint dans le répertoire, ... et un beau jour la progression vers la conformité au gedcom.

Et sauf erreur de ma part (corrigez moi si je me trompe), il reste, dans la saisie rapide,

-les dates invalides qui n'apparaissent plus en rouge

-la présentation prédictive des prénoms déjà connus,

-le sexe associé à ces prénoms

[Bob du Vaucluse]

bonjour

dans la foulé, le passage en Majucule de la première lettre de la description d'un événement (individuel ou fmaillialle)



pas mal, et cela eviter de faire des coups de BOA

UPDATE EVENEMENTS_IND SET EV_IND_DESCRIPTION = UPPER ( substr (EV_IND_DESCRIPTION,1,1)) || (substr (EV_IND_DESCRIPTION,2,(STRLEN (EV_IND_DESCRIPTION))))  where  EV_IND_DESCRIPTION Is not null  

merci

[DDdeBerdeux]

Bonjour,

dans la foulé, le passage en Majucule de la première lettre de la description d'un événement (individuel ou fmaillialle)

Cà, ce n'est pas trop difficile et à ma portée. Il a suffit d'ajouter un trigger  aux tables événements dans cette b5.014. J'ai étendu le principe aux champs Cause et Titre (si événement divers), en plus de la Description. Pour les champs Informations et Sources on verra plus tard, car ce n'est pas aussi simple; il faudrait ajouter une fonction UDF pour traiter les champs BLOB.

Dans la foulée, je me demande si le même principe devrait prévaloir pour les champs Date. Si vous voulez le faire, il faut que le mode d'interprétation des dates soit sur LIT ou NUM (Forme dans les "Mots clefs utilisés dans les dates"), et que les mots clefs ad hoc soient modifiés ("De" à la place de "de", "Avant" au lieu de "avant", Vers, Calculée etc).

Je l'ai fait dans la base vide qui est jointe. Le plus simple pour voir ce que celà donne consiste à importer votre généalogie perso dans cette base vide, car cette transformation n'intervient que lors de la création ou modification. La modification de la casse ne devrait pas poser de problèmes, car depuis quelques versions de la base, les mots clefs doivent être reconnus indépendamment de la casse et des accents. (les variantes avec accents erronés pourraient être supprimées de la table de références sans inconvénients)

La question peut aussi se poser pour la première lettre du mois. Y a-t-il une règle dans ce cas?

A+

André

[Tophe3860]

La question peut aussi se poser pour la première lettre du mois. Y a-t-il une règle dans ce cas?

Un 1er avis...

Les mois sont des noms communs...

Donc, il ne devrait pas y avoir d'initiale en majuscule...



Après vérification, pas de majuscules...

les noms de mois et de jour prennent une minuscule sauf s'ils désignent une date historique :

ex : le 18 juin 2005, mais l'appel du 18 Juin, le 14 Juillet

[Facon]

Bonjour André,

Dans la foulée, je me demande si le même principe devrait prévaloir pour les champs Date. Si vous voulez le faire, il faut que le mode d'interprétation des dates soit sur LIT ou NUM (Forme dans les "Mots clefs utilisés dans les dates"), et que les mots clefs ad hoc soient modifiés ("De" à la place de "de", "Avant" au lieu de "avant", Vers, Calculée etc).

Je l'ai fait dans la base vide qui est jointe. Le plus simple pour voir ce que celà donne consiste à importer votre généalogie perso dans cette base vide, car cette transformation n'intervient que lors de la création ou modification. La modification de la casse ne devrait pas poser de problèmes, car depuis quelques versions de la base, les mots clefs doivent être reconnus indépendamment de la casse et des accents. (les variantes avec accents erronés pourraient être supprimées de la table de références sans inconvénients)

La question peut aussi se poser pour la première lettre du mois. Y a-t-il une règle dans ce cas?

  Pour ma part, je trouve les dates très bien comme elles sont et je ne vois pas un intérêt particulier à mettre des majuscules ni au de, vers, entre, ... ni au mois.

  Ce qui serait bien, c'est d'avoir le cas échéant les dates en grégorien et républicain mais encore une fois ce n'est pas primordial.

  Ce qui serait mieux, c'est d'avancer sur les points encore en anomalie et de clarifier les installations des mises à jour pour lesquelles il reste des soucis récurrents.

  Il faudrait enfin statuer sur quelques améliorations dans l'utilisation qui ont été suggérées au fil du temps.

Tout n'est pas forcément ou uniquement du ressort de la base.

[JiPSchiff]

.... on risque de se retrouver un ancetre cromagnon  

On y arrive,regarde mon Avatar(mais je n'ai pas trouvé l'acte)  

[Joël AUGUSTE]

La question peut aussi se poser pour la première lettre du mois. Y a-t-il une règle dans ce cas?

Bonjour,



Dans le Petit Robert, on trouve 14 Juillet avec un "J" majuscule.

Dans le Littré il est écrit 14 juillet avec un "j" minuscule.

Dans le dictionnaire de l'Académie française, selon l'édition, on trouve les 2 orthographes. La dernière édition prévoit une lettre minuscule.

[Pierre Garnier]

Il me semble les noms de mois ne sont pas des noms propres et la règle veux qu'on ne mette pas de majuscule ; mais tout évolue ...

[BLefebvre]

  Ce qui serait mieux, c'est d'avancer sur les points encore en anomalie et de clarifier les installations des mises à jour pour lesquelles il reste des soucis récurrents.

  Il faudrait enfin statuer sur quelques améliorations dans l'utilisation qui ont été suggérées au fil du temps.

Tout n'est pas forcément ou uniquement du ressort de la base.

Tout à fait d'accord. Arrêtez d'inventer des trucs et des machins qui sont d'un intérêt relatif. Pour la première lettre de la description en majuscule, ce n'est quand même pas sorcier d'appuyer sur la touche shift, et ça ne remplace pas les dates mal écrites en rouge (entre autres).

[AquaBlue]

dans la foulé, le passage en Majucule de la première lettre de la description d'un événement (individuel ou fmaillialle)

Cà, ce n'est pas trop difficile et à ma portée. Il a suffit d'ajouter un trigger  aux tables événements dans cette b5.014. J'ai étendu le principe aux champs Cause et Titre (si événement divers), en plus de la Description.

Ça c'est une très mauvaise idée  

Cela va pourrir le développement éventuel d'une éditon "racontée" de votre généalogie (comme ça existe dans Visuged, GeneWeb, Filiatus ...) car cette "majuscule" se retrouvera sans aucune raison derrière une virgule ou en plein milieu d'une phrase.

Il serait plus judicieux de ne rajouter la majuscule qu'à l'affichage et surtout pas dans la base.

[Tophe3860]

• Excellent argument pour :

- garder la minuscule à l'initiale des champs "texte"...

- qu'il n'y ait pas de majuscule d'office pour l'initiale de la profession renseignée dans la fiche "saisi rapide"

Ça c'est une très mauvaise idée  

Cela va pourrir le développement éventuel d'une éditon "racontée" de votre généalogie (comme ça existe dans Visuged, GeneWeb, Filiatus ...) car cette "majuscule" se retrouvera sans aucune raison derrière une virgule ou en plein milieu d'une phrase

• Pour l'histoire de la majuscule du mois, les avis et recherches concordent vers pas de majuscule non plus...  
  
  
  
  
• Les dernières nouveautés sont excellentes : améliorations bases, frises, etc...

Mais, je rejoins ceux qui n'oublient pas les améliorations / corrections nécessaires sur le fonds...

Sans vouloir mettre du sel sur la plaie, l' "accroche" au lancement du site Ancestrologie mentionne "100% efficace" : certaines modifs ne sont-elles pas essentielles, fondamentales pour qu'Ancestrologie gagne en crédibilité et en souplesse à l'export / import... et tendre vers cette efficacité? [/list]

[DDdeBerdeux]

Bonjour,

Bob ne va pas être content, mais l'argument me semble recevable, surtout pour la Description qui concerne souvent une profession.

Pour le Titre (qui remplace l'intitulé de l'événement Divers), les intitulés ayant déjà une première lettre en majuscule, je pense logique de la conserver.

Pour la Cause qu'en est-il?

Je ne pense pas non plus que ce soit une bonne idée de ne mettre cette majuscule qu'à l'affichage, car dans la fiche le champ qui affiche est également celui qui enregistre. Comment alors distinguer la majuscule "d'affichage" de celle tapée par l'utilisateur au moment de l'enregistrement? Sans doûte pas impossible informatiquement, mais sûrement complexe (double gestion). Celà serait plus simple dans les états, documents "à imprimer".

Pour les évolutions moins "cosmétiques", ne perdez pas espoir, Philippe s'y remet...

A+

André

[Bob du Vaucluse]

Bonjour



Content pas content ce n'est pas le problème.

De ma fenêtre je voyais un plus, mais … que chacun s’exprime

Je n’utilise pas de truc  "racontant" ma généalogie

Mais par contre il y avait un peu de brouillard pour les regroupements par professions entre autre.

Donc UN normalisation, par exemple Maitre Couvreur devient Couvreur (Maitre) etc

DEUX je n’ai pas toujours mis de majuscule d’ou ma demande.

Mais s’il est plus cohérant, rationnel, de rester en minuscule pas de problème (bis).



En plus comme disent les toubibs c’était du confort



Enfin j’ai différentié Titre et Profession, mais Bruno ne traite (pas encre) les titres, alors ….



Et Merci André pour ta compassion