Sujet: Liste des anniversaires

[patschw]

Bonjour,
J’ai certainement loupé un épisode concernant le traitement des anniversaires car la liste ne fonctionne plus. Je suppose qu’un traitement ponctuel qui consistait à enrichir les nouveaux champ de la table des événements individuels n’est plus présent dans les derniers protocoles de migration. Je le constate en passant d’une base 4.031 à 5.053. En revanche, ces champs sont bien complétés en création d’individu.
Si ce point a déjà été évoqué, merci de me donner le topic car je n'ai pas trouvé.
Cordialement,
Patrick

[Facon]

Bonsoir,
Si tu parles de la Liste des Anniversaires accessible depuis le menu Impressions, Documents, je ne pense pas qu'il y ait eu un changement de portage dans Ancestrologie.
Peux-tu préciser ta question pour être bien certain de répondre convenablement?

[patschw]

Absolument, il s'agit de la liste accessible par le menu vertical à gauche.
Mais, le résultat est identique si je passe par les documents à imprimer.
"Aucune donnée trouvée" semble bien indiquer des paramètres manquants maintenant quelque part.
Il doit s'agir d'un champ EV.IND.MOIS (ou qqchose comme çà) qui n'est pas renseigné.
Je pense donc que j'ai loupé une migration indispensable.
Cordialement
Patrick

[Facon]

Bonjour,
Dans la fenêtre d'affichage de la liste des anniversaires, as-tu contrôlé le contenu de la requête au travers du bouton Paramètres. En particulier est-ce que au moins un type d'événement est coché?

Si tu as encore des difficultés, tu nous rappelles les versions en cours d'Ancestrologie sachant que nous avons noté que la base était b5.053. De même tu préciseras le moyen utilisé pour faire la migration depuis b4.031 vers la version ci-dessus.
Toutes les données sont dans la base, si en définitive tu ne trouvais pas de solution à ta question, il restera la possibilité du transfert de tes données vers une base vide neuve.

[patschw]

J’ai bien coché les cases.
Il y a dans la table EVENEMENTS_IND un champ EV_IND_DATE_MOIS dont toutes les lignes sont à NULL. En toute logique, ces lignes devraient indiquer le mois de l’événement.
Dans la récente procédure d’André, c’est d’ailleurs cet INTEGER qui sert de tri pour tester la sélection. Il est mis à jour à chaque intervention (ou création) sur un événement.
Comme je ne monte pas mes versions au fur et à mesure des publications, je viens seulement de passer, en test, d’une 4.031 à la 5.053 qui est comprise dans un .exe de 8209ko téléchargé le  09/02/2008 (migration_base2008.773.5.053).
Je ne suis pas certain qu’un transfert dans une base vide résolve le problème car les données nécessaires aux nouveaux champs n’existent pas dans l’ancienne base. Elles doivent être calculées : extraction du quantième du mois, par exemple.
Sous réserve évidemment que mon hypothèse soit confirmée.
Cordialement,   

[DDdeBerdeux]

Bonjour,
Le transfert devrait résoudre le problème, les champs année et mois étant calculés lors de l'enregistrement à partir de la date "écrite" (celle en toutes lettres, saisie à l'écran à l'origine).
A+
André

[patschw]

Bonjour,
Sauf que le champ MOIS n'est pas dans les bases d'origine. N'a-t-il pas été créé postérieurement à la 4031 ?
Cordialement,
Patrick

[DDdeBerdeux]

Pas besoin, puisqu'il est calculé lors du transfert....
André

[patschw]

Bon ! Toujours est-il que ce champ est à NULL sur toutes les lignes. Finalement, je m’y suis pris autrement pour y arriver, mais j’ignore les vrais raisons du problème. Peut-être un TOKEN DATE 24 absent dans la base d'origine.
A+
Patrick

[DDdeBerdeux]

Bonsoir,

Finalement, je m’y suis pris autrement pour y arriver, mais j’ignore les vrais raisons du problème. Peut-être un TOKEN DATE 24 absent dans la base d'origine.

Il serait étonnant que le token 24 reste absent longtemps, s'il est absent il est automatiquement créé à 'LIT', dès la première utilisation de la procédure de décodage de la date écrite...
Qu'entendez-vous par "je m'y suis pris autrement"?
A+
André

[patschw]

Il serait étonnant que le token 24 reste absent longtemps, s'il est absent il est automatiquement créé à 'LIT', dès la première utilisation

C’est certainement ce qui se passe , mais dans ma nouvelle base, si les champs EV_IND_MOIS sont restés à NULL, c'est qu’un test n’a pas poursuivi le calcul à la première migration.
( if (FORME NOT IN('LIT','NUM','NON') or MODE_MAJ NOT IN(0,1,2)) then EXIT )
Action corrective : modification de T_VERSION_BASE avec 5.052 au lieu de 5.053 puis re migration et les calculs se sont bien effectués. Mais je me dis que ce n’est peut-être pas la bonne solution.
Amicalement,
Patrick

[Facon]

Bonjour,
En abordant la question différemment:

Comme je ne monte pas mes versions au fur et à mesure des publications, je viens seulement de passer, en test, d’une 4.031 à la 5.053 qui est comprise dans un .exe de 8209ko téléchargé le  09/02/2008 (migration_base2008.773.5.053).

Tu indiques pour l'outil de migration migration_base.exe 2008.773.5.5053 une taille de 8209 ko. Dans mes archives et encore sur le site aujourd'hui le même exécutable a une taille de 8405 ko (8 405 212 octets pour être précis).
N'y a-t-il pas un problème de ce côté?

[DDdeBerdeux]

Bonjour,
En informatique, un kilo c'est un mot de 10 bits, soit 2^10=1024.
8 405 212 / 1024 = 8208.2148375 que l'affichage doit arrondir à 8209.

Lors du passage en b5.046 début décembre, j'ai noté ceci dans le fichier modificationBDDInv.txt (le fichier de suivi des modifications de la base qui accompagne le base vide en ligne sur mon site): "Modification de PROC_DATE_WRITEN pour éviter erreurs en cas d'effacement de la valeur du paramètre FORME dans la table REF_TOKEN_DATE."
Je m'étais aperçu que certains utilisateurs avaient des problèmes suite à un effacement de la valeur de FORME (involontaire je l'espère, peut-être en voulant remplacer LIT par NUM). La procédure jusqu'à la version b5.045 ne faisait que la création d'un token 24 si la valeur de FORME n'était pas trouvée. En conséquence si la valeur avait été effacée, il était créé un deuxième enregistrement token 24, qui malheureusement n'était pas utilisé, puisque seul le premier est lu. Ce qui pouvait entrainer la création d'un troisième enregistrement token 24 la fois suivante etc....
A partir de la version b5.046, la valeur LIT est écrite si le token existe mais que sa valeur est NULL.
Pour infos, à partir de la version b5.056, la base prenant en charge le décodage de la date lors de l'importation d'un fichier gedcom, FORME est obligatoirement mise à LIT s'il n'est pas LIT ou NUM, et ORDRE à DMY (jour, mois, année) au début de l'importation.

Dans quelle procédure, de quelle version de la base avez-vous trouvé "( if (FORME NOT IN('LIT','NUM','NON') or MODE_MAJ NOT IN(0,1,2)) then EXIT )"?

A+
André

[patschw]

Dans la PROC_MAJ_FORMAT_DATE de la version 5.053, mon Capitaine ! (sans les premières parenthèses).

La procédure jusqu'à la version b5.045 ne faisait que la création d'un token 24 si la valeur de FORME n'était pas trouvée.

En analysant les données, j’ai eu l’impression que cela allait se passer en deux temps :
première migration = préparation des champs
migration suivante = exécution des extractions de date
A l’époque, les versions devaient se succéder à un rythme effrénée, et cela pouvait ne pas être visible si la liste des anniversaires n’était pas requise avant la montée de version suivante. Mais je me suis retrouvé entre les deux. Ce n’est toujours qu’une hypothèse. De toutes les façons, ce n’est pas bien grave. Et puis cela fonctionne à nouveau.
Cordialement,
Patrick   

[DDdeBerdeux]

Sur chacune des tables evenements_fam et evenements_ind, des triggers before insert et before update, analysent le champ "date écrite" et mettent à jour si nécessaire les champs "année", "mois" et "date" (extrayant même des valeurs année_fin, mois_fin et date_fin si la date écrite est une période).

La PROC_MAJ_FORME_DATE a été créée pour:
1- permettre la modification du champ "Forme" car à l'époque il n'était pas accessible dans la fiche des Token-dates,
2- appliquer (ou non selon la valeur de MODE_MAJ) la nouvelle forme d'écriture des dates aux valeurs existantes.
Et dans ce second rôle, elle a été appliquée lors de la mise à jour des bases existantes, quand les champs "mois" et ceux de la fin de période ont été ajoutés.
Mais dans "if (FORME NOT IN('LIT','NUM','NON') or MODE_MAJ NOT IN(0,1,2)) then EXIT" les valeurs FORME et MODE_MAJ sont des variables d'entrée. En particulier FORME est la valeur que vous souhaitez donner au champ "FORME", et non la valeur qui s'y trouve déjà. Il ne s'agit que d'un test pour éviter de mettre n'importe quelle valeur dans ce champ.

A+
André

[patschw]

Bien, bien !
Merci pour toutes ces explications.
A+
Patrick