Si certains veulent bien essayer cette version (sur une copie de leur base par sécurité), le fichier de mise à jour est à télécharger
ICI et la base vide accompagnée de la liste complète des modifications
LA .
Pour éviter quelques erreurs, la version V524 du logiciel est nécessaire, Philippe ne devrait pas tarder à la mettre en ligne.
Depuis la version b4.031 les modifications sont les suivantes:
PROC_VILLES_FAVORIS suppression CAST inutiles (accélération).
Ajout dans la procédure de maj, du champ CLE_FIXE et des triggers qui vont avec dans la table INDIVIDU, de NCHI et NMR pour réparer certaines bases dont la migration aurait été faîte alors qu'elles n'étaient pas en b3.57.
Suppression du TRIGGER INDIVIDU_AU inutile et qui provoque une erreur sous FB2.0.
Corrections de la PROC_COMPTE_ONGLETS pour erreurs d'apparition du point vert sur l'onglet "Médias".
Création de la table T_GROUPES et des PROC_LR_SEL_GROUPE et PROC_LR_MIX_GROUPES qui semblent "oubliées" dans certaines bases qui ont été mises en ligne.
Modification de PROC_LR_SEL_GROUPE pour erreur sur la sélection des ascendants et descendants (I_MODE=2), vu avec Laurent Robbe.
Modification des champs BLOB sub_type 2 (BLR) en sub_type 0 mieux adapté au stockage des images et reconnu par les autres logiciels lorsqu'ils contiennent des images.
Création procédure PROC_DATE_WRITEN_UN et modification PROC_DATE_WRITEN pour identifier des dates de fin d'un évènement lorsque la date est saisie sous la forme "entre le XX/XX/XXXX et le XX/XX/XXXX". PROC_DATE_WRITEN peut "normaliser" les dates sous une forme littéraire ou numérique, suivant la valeur d'un nouveau TOKEN_DATE de TYPE_TOKEN=23, TOKEN="LIT' ou 'NUM' ou 'NON'.
Ajout aux tables ADRESSES_IND, EVENEMENTS_IND et EVENEMENTS_FAM des champs MOIS, MOIS_FIN, AN_FIN et DATE_FIN et modification des triggers pour documenter ces champs. Mise à jour de ces champs par la procédure de mise à jour.
Création de la PROC_MAJ_FORME_DATE pour changer le TYPE_TOKEN 23 en LIT, NUM ou NON en mettant à jour les dates calculées et saisies selon la valeur du token.
Création d'une fiche familiale "Fiche_familiale_inv.rtm" où la vie du couple est avant les enfants, sans saut de page.
Quelques commentaires:
La principale nouveauté de cette version, a pour origine un message de Christophe
http://www.ancestrologie.org/forum/index.php?topic=5721.0Il m'a permis de constater que s'il est possible dans les évènement de saisir des dates sous la forme "entre le 19/11/1945 et décembre 1946", il n'y avait que la première date et son année qui étaient mémorisées et exploitables dans des requêtes. J'ai donc ajouté la mémorisation de la deuxième date et année, ainsi que les mois des 2 dates dans les tables évènements. Il faut comprendre cette 2ième date comme une date limite supérieure avant laquelle l'évènement est intervenu. Elle peut donc être documenté même s'il n'y a qu'une seule date saisie, si cette date est précédée d'un mot clé (token_date) du type "avant". Les 2 dates peuvent même être inversées si on a saisi par exemple "entre date1 et date2" et que date1>date2. Les noms des champs concernés se terminent par "_FIN".
Pour répondre à la demande de certains (P.Horemans, Lya) qui souhaitent pouvoir saisir rapidement des dates sous la forme "numérique" (19/11/1945) mais que celle-ci s'affiche sous la forme "littéraire" (19 novembre 1945), cette possibilité a été intégrée à la procédure PROC_DATE_WRITEN qui met à jour les champs dates.
Afin de ne pas "imposer" à tout le monde ce type de fonctionnement (d'autres peuvent préférer le forme numérique, ou que leur saisie ne soit pas modifiée), un nouveau type (24) de TOKEN a été ajouté à la table REF_TOKEN_DATE.
Il peut prendre les valeurs 'LIT', 'NUM' ou 'NON'.
'LIT' met la date sous forme littéraire
'NUM' sous forme numérique
'NON' la laisse comme saisie.
A la première utilisation cette variable est initialisée à 'LIT'.
Pour que celà fonctionne, il ne faut pas utiliser dans le champ de saisie de la date, des mots qui n'appartiennent pas à la "Liste des mots clés utilisés dans les dates" (menu configuration). Si cette condition n'est pas respectée, la date saisie n'est pas modifiée, et les champs date, mois, année pas documentés.
Dans la forme litéraire, le mois est remplacé par le premier nom du mois figurant dans la liste des mots clés. Donc si certains préfèrent normaliser leurs dates en "janv" au lieu de "janvier", ils doivent changer l'ordre dans cette liste.
La procédure PROC_MAJ_FORME_DATE a été ajoutée pour définir ce mode de fonctionnement et mettre à jour les champs dans la base. Elle doit être exécutée dans le BOA par l'instruction:
EXECUTE PROCEDURE PROC_MAJ_FORME_DATE(FORME,MODE_MAJ)
FORME doit prendre l'une des 3 valeurs 'LIT', 'NUM' ou 'NON' pour définir le mode de fonctionnement comme expliqué ci-dessus.
MODE_MAJ peut prendre les valeurs 0, 1 ou 2.
0 ne change que le mode de fonctionnement.
1 recalcule en plus les champs date, mois et année
2 effectue en plus la "normalisation" des champs dates saises selon la forme définie, dans toute la base.
Pourquoi la V524? Afin de pouvoir ajouter des champs aux différentes tables, Philippe a dû modifier son exécutable qui sans celà provoquait des erreurs lors de certaines fonctions (import gedcom par exemple). Comme dans cette version il a également réparé certaines actions à l'origine des erreurs de répertoire, que j'avais bloquées par les triggers, j'ai remis les triggers dans leur forme normale. Donc ils ne bloquent plus les erreurs des anciennes versions.
Le WE s'annonce froid et pluvieux. Donc bons tests.
André
PS: la V524 est en bêta
http://www.ancestrologie.org/france/majbeta/Ancestrologie.exeRéédition; voir message du 07/06/2006 pour passage à b4.034