forum Ancestrologie
Ancestrologie - Développement => Développement => Discussion démarrée par: DDdeBerdeux le 02 Juin 2006 à 15:21:30
-
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 (http://andre.langlet.free.fr/ancestro/maj_b357_b4035.exe) et la base vide accompagnée de la liste complète des modifications LA (http://andre.langlet.free.fr/ancestro/FAMILLEVIDE4035.zip).
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.0
Il 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. :wink:
André
PS: la V524 est en bêta http://www.ancestrologie.org/france/majbeta/Ancestrologie.exe
Réédition; voir message du 07/06/2006 pour passage à b4.034
-
Bonsoir,
Je viens d'encoder une grosse quantitée de données avec la version béta et n'ai rencontré aucun problème ni aucun plantage
-
Ouf, tout le monde n'est pas à Roland Garros :?
Petites questions sur la présentation normalisée de la date:
Sous la forme littéraire comme sous la numérique, le jour est présentée par 2 chiffres (en ajoutant le 0 devant si nécessaire), et l'année sur 4 chiffres. Celà me semble indispensable dans la forme numérique (XX/XX/XXXX).
Est-ce que celà vous gêne dans la forme littéraire? J'aurai la possibilité de laisser ces nombres sans les 0 par le code, mais çà ne peut pas être laissé au choix de l'utilisateur.
Dans la forme numérique, le séparateur est le "/". Je pourrai le laisser au choix de l'utilisateur (premier des séparateurs dans la liste des mots clés utilisés dans les dates).
Est-ce que çà vous intéresse?
Vous avez peut-être remarqué que la "normalisation" ne concerne que la présentation de la date et non les mots clés (token date). Je ne l'ai pas fait dans cette version parce que celà faisait trop de problèmes à résoudre à la fois et qu'il faudrait modifier la table de référence et la fiche qui donne accès aux mots clés. Un même type_token peut en effet être traduit sous différentes formes littéraires selon la forme de la date.
A BEF par exemple correspond "avant", "avant le", "avant l'année" et autres variantes avec fautes d'orthographes mises en mots clés pour qu'ancestro puisse les interpréter.
Je pense avoir trouver une logique pour choisir le bon mot clé.
Cette normalisation peut-être intéressante car elle permettrait principalement d'améliorer la présentation après un import gedcom où actuellement le premier mot clé du token-date est systématiquement utilisé. ex "avant 19 janvier 1900" au lieu de "avant le 19 janvier 1900".
Est-ce que çà intéresse quelqu'un que je programme cette normalisation?
A+
André
-
Bonjour André,
Personellement, le zéro ne me gêne pas.
Pour le séparateur j'utilise toujours le / donc pas de problème. mais peut-être que d'autres utilisent un autre séparateur, donc il serait bon d'avoir le choix.
Cela serait un plus pour l'esthétique si effectivement il était écrit "Avant le 19 janvier 1900", pour autant que lorsque l'on encode uniquement l'année il ne soit pas écrit "Avant le 1900" par exemple.
Mais ceci n'est que mon point de vue :D
Bonne journée.
-
D'accord avec Pierrot, je n'utilise que la forme xx/xx/xxxx dans MES saisies, mais les imports gedcom donnent un peu de tout.
Tout outil de normalisation est le bienvenu de même que tout ce qui améliore la présentation.
L'idéal serait donc d'avoir des formes minimum mais rigoureuses pour la saisie et des formes plus littéraires pour les documents de sortie.
Je n'apporte pas d'élément supplémentaire, mais j'approuve. :)
-
Le 0 n'est pas gênant dans une forme littéraire. Si tu commences à mettre le doigt dans de telles modifs, il va falloir aussi mettre er derrière 1 (1er) etc...
Il y a des programmes de présentation qui permettent çà (Généalogica Graphica - Filiatus)
Penses-tu faire une normalisation générale des dates (et pas seulement la présentation) ?
Ce genre de modif pourrait être intégrée au BOA pour traiter les import gedcom issus d'autres programmes.
-
D'accord avec Pierrot, je n'utilise que la forme xx/xx/xxxx dans MES saisies, mais les imports gedcom donnent un peu de tout.
Déjà tu dois voir que, si tu as laissé la forme LIT comme elle se met lors de la mise à jour en b4.033, la date saisie est transformée en littéraire, tout comme lors de l'importation d'un gedcom. Si celà ne se fait pas, c'est que sans doûte les mots clés utilisés ne sont pas corrects.
J'ai fait dans ma base perso la modif pour supprimer les zéros des jours et années en forme littéraire et le séparateur de la forme numérique. La présentation est meilleure. Je vous la communiquerai dans une version b4.034. Mais j'essaie la normalisation des mots clés avant de vous l'envoyer.
A+
André
-
Hello André,
J'allais te demander si la suppression du 0 en forme littéraire était possible, mais je vois que tu y as déjà pensé ! :wink:
Le choix du séparateur est aussi intéressant, je souscris donc au "oui".
Par contre, j'ai un problème avec ta procédure : ça marche bien avec mode_maj = 0 mais j'obtiens un "Erreur lors de l'accès aux données" avec le choix 1 ou 2. Et mes colonnes mois sont toujours vides sauf pour ceux que je modifie après application du choix 0 :?:
En tout cas, superbe travail comme toujours ! Merci aux courageux qui travaillent le lundi de Pentecôte :!: :lol: :wink:
-
j'obtiens un "Erreur lors de l'accès aux données" avec le choix 1 ou 2.
Même souci
-
Bizarre, je n'ai pas cette erreur. Et suite à vos messages, j'ai même fait l'essai avec une ancienne base b3.57, et la maj s'est exécutée sans problème, tout comme les requêtes avec IBOConsole et le BOA.
Pourriez-vous regarder la fin du fichier modifbase.log qui se trouve dans le répertoire ancestrologie. Il contient tous les messages émis pendant la maj. Depuis les dernières versions, je met entre 2 lignes de commentaires qui l'indiquent, les instructions qui peuvent provoquer normalement des erreurs. Normalement le fichier doit se terminer par:unsuccessful metadata update
-Procedure PROC_LR_SEL_GROUPE already exists
COMMIT WORK^
/*Fin des erreurs normales*/
SET ECHO OFF^
/*Passage en version 4.033
L'utilisation de la base modifiée avec une version du logiciel inférieure à V524 peut entraîner des disfonctonnements.*/
SET ECHO OFF^
La mise à jour des champs MOIS intervient après la ligne /*Fin des erreurs normales*/, et est faîte par la PROC_MAJ_FORME_DATE en mode 1. S'il y a eu des erreurs, vous devriez les retrouver là.
Dans le BOA, l'exécution de l'instruction
EXECUTE PROCEDURE PROC_MAJ_FORME_DATE('LIT',2)
s'obtient en cliquant sur le bouton "Exécuter la procédure", et LIT doit être entouré de simples cotes.
A+
André
-
Moi, j'ai ça :
unsuccessful metadata update
-Procedure PROC_LR_SEL_GROUPE already exists
COMMIT WORK^
/*Fin des erreurs normales*/
SET ECHO OFF^
Statement failed, SQLCODE = -413
conversion error from string "-"
/*Passage en version 4.033
L'utilisation de la base modifiée avec une version du logiciel inférieure à V524 peut entraîner des disfonctonnements.*/
SET ECHO OFF^
-
et moi ça, depuis 4.028
SET ECHO OFF^
Statement failed, SQLCODE = -802
arithmetic exception, numeric overflow, or string truncation
/*Passage en version 4.033De plus j'arrive pas avec BOA il me dit erreur d'accés aux données, il faut bien faire: EXECUTE PROCEDURE PROC_MAJ_FORME_DATE('LIT',1) et exécuter procédure ?
Bon, vais jeter un coup d'oeil dans IBexpert, mais vu l'heure vais pas trainer :wink:
[EDIT:] Pour info dans IbExpert j'obtiens:
Arithmetic overflow or division by zero has occurred.
arithmetic exception, numeric overflow, or string truncation.
[EDIT 2:] :idea: Une piste :arrow: j'ai pas de typetoken à 24, ils s'arrêtent a 23 :roll:
[EDIT 3:] :oops: aie! non j'ai rien dit, c'est que tu le crées le 24, he ben chez moi il se crée pas, puisque ça plante :?
Sur ce ... Bonne nuit 8)
-
J'ai rigoureusement la même chose que Bruno.
-
Bonjour,
Le type_token 24 est créé la première fois que la PROC_DATE_WRITEN (procédure qui calcule les différentes valeurs) est exécutée. Elle est donc utilisée lors de l'exécution de PROC_MAJ_FORME_DATE('LIT',1) au cours de la maj de la base. S'exécutant donc dans la même transaction la création est annulée si une erreur intervient lors de l'exécution de PROC_MAJ_FORME_DATE.
Mais PROC_DATE_WRITEN s'exécute seule ensuite à chaque fois qu'on modifie la saisie d'une date. Pourriez-vous me dire si vous avez une erreur lors de cette saisie? Le champ MOIS correspondant est-il alors bien documenté et le type_token 24 ajouté?
Cà me permettrait de savoir dans quelle procédure il y a un problème.
Pour Lya, n'y aurait-il pas une date avec un signe moins? Que se passe-t-il si le signe moins est ajouté dans la liste des séparateurs?
A+
André
-
Bonsoir à tous :)
Pour Lya, n'y aurait-il pas une date avec un signe moins? Que se passe-t-il si le signe moins est ajouté dans la liste des séparateurs?
C'était bien ça. J'avais plusieurs dates-intervalles sous la forme "1845-1899". Après les avoir rectifiées en "entre 1845 et 1899" et relancé l'outil de migration de la base, tout est rentré dans l'ordre et je peux maintenant utiliser ta procédure.
Donc c'est Ok chez moi. Merci André. :P :wink:
-
Pourriez-vous me dire si vous avez une erreur lors de cette saisie? Le champ MOIS correspondant est-il alors bien documenté et le type_token 24 ajouté?
Peux-tu être plus explicite, j'arrive à mes limites :
Je saisie une date sur un événement sans problème, mais après ? :oops:
Et comme je ne veux pas mourir stupide...
-
Mais PROC_DATE_WRITEN s'exécute seule ensuite à chaque fois qu'on modifie la saisie d'une date. Pourriez-vous me dire si vous avez une erreur lors de cette saisie? Le champ MOIS correspondant est-il alors bien documenté et le type_token 24 ajouté?
Bonjour André, comme le dit Philippe H. :roll: :shock: :?: (à moins que tu n'entendes le mois est converti en littéral par 'documenté')
Je viens d'essayer :
1 - avec une saisie 'vers 14/12/1674' sans erreur, convertie dans l'evenement en 'vers 14 décembre 1674'
2 - vérification dans ibExpert, le token 24 a bien été créé ce coup là
3 - lancement de la procédure dans ibexpert = erreur idem hier
4 - lancement de la procédure dans boa = erreur idem hier ( et de plus la sortie du Boa suite à l'erreur ne me redonnes pas la main sur ancestro, ctrlaltsupr :cry: :evil: mais ça c'est pour Lau et PCM :wink: )
Espérant que celà t'aides un peu
-
J'avais plusieurs dates-intervalles sous la forme "1845-1899". Après les avoir rectifiées en "entre 1845 et 1899" et relancé l'outil de migration de la base, tout est rentré dans l'ordre et je peux maintenant utiliser ta procédure
Bonsoir,
Enfin une chez qui çà marche, mais ce serait mieux si cette erreur pouvait ne pas planter le reste de la mise à jour. Je vais chercher une solution, car j'ai l'impression que Lya n'est pas la seule concernée.
Dans la table ADRESSES_IND, j'ai ajouté les champs, ADR_DATE_MOIS_1 et ADR_DATE_MOIS_2
Dans EVENEMENTS_FAM, EV_FAM_DATE_MOIS, EV_FAM_DATE_MOIS_FIN, EV_FAM_YEAR_MOIS et EV_FAM_DATE_FIN
Dans EVENEMENTS_IND, EV_IND_DATE_MOIS, EV_IND_DATE_MOIS_FIN, EV_IND_YEAR_MOIS et EV_IND_DATE_FIN
pour mémoriser le mois de la première date, le mois, l'année et la date exacte (si possible) de la date de fin.
Par "documenté", je voulais demander si les champs MOIS de la première date ci-dessus étaient remplis (par le n° du mois). Pour la date de FIN, il peut arriver que la date de fin soit remplie même s'il n'y a qu'une date saisie; dans le cas de "avant XX/XX/XXXX".
A+
André
-
Je viens d'essayer d'entrer une date type vers 14/05/2006 en sortie j'ai bien 14 mai 2006 :wink:
-
J'obtiens bien la forme littéraire à la confirmation de la saisie d'un événement, mais la procédure de mise à jour dans le BOA affiche le message d'anomalie, chez moi après avoir mouliné plusieurs minutes. Je n'ai pas validé avant de quitter.
-
Bon pas de temps à perdre :lol:
Je voulais essayer sur autre config, mais plus de maj 4.033, j'ai essayer 4.034 et voilà:/*Fin des erreurs normales*/
SET ECHO OFF^
/*Passage en version 4.034
L'utilisation de la base modifiée avec une version du logiciel inférieure à V524 peut entraîner des disfonctonnements.*/
SET ECHO OFF^[/size]à priori pas d'erreur là et le BOA à fonctionné :wink: mais je suis sur un autre système et autre base ,je reéssayerai ce soir depuis la même config qu'essais précédents
-
Parfait pour moi, la base est à jour et tout s'affiche en forme littéraire.
Encore de la belle ouvrage !
-
Je voulais essayer sur autre config, mais plus de maj 4.033, j'ai essayer 4.034
Bonjour,
Tu es allé un peu trop vite. J'avais mis la b4.034 sur mon site, sans modifier les liens du premier message, mais je l'ai remodifiée pour corriger une erreur sur un token ("entre l'année" mis en type 13 au lieu de 17), avant de modifier les liens. Il faudra donc que tu refasses la maj.
Mais ton essai confirme que la modification que j'ai faite pour qu'il n'y ai plus d'erreur quand il y a un signe + ou - non suivi d'un chiffre, a été efficace. Je ne voulais pas supprimer la possibilité d'enregistrer des dates av JC. Même si Firebird ne sait pas convertir une date négative en type DATE, l'année et le mois sont enregistrés (si quelqu'un veut faire la généalogie de Ramsès II :) )
Si des mots inconnus de la liste des mots clés sont utilisés lors de la saisie de la date, les champs MOIS YEAR et DATE sont mis à NULL et la date saisie n'est pas "normalisée".
La réelle nouveauté de cette version, c'est que cette "normalisation" touche maintenant les mots clés (si FORME est 'LIT' ou 'NUM').
Pour y arriver, j'ai ajouté un champ SOUS_TYPE à la table REF_TOKEN_DATE.
La difficulté était de savoir comment choisir le bon mot clé dans la liste des mots clés d'un même type. SOUS_TYPE prend la valeur:
'D' si la date comprend le jour (ex: avant le 12 décembre 1900)
'M' si la date commence par le mois (ex: avant décembre 1900)
'Y' s'il n'y a que l'année (ex: avant l'année 1900)
Dans un même type_token, le mot clé est choisi dans l'ordre des sous_types (D, M, Y, le premier des mots), en commencant par exemple par M si le mois existe mais pas le jour.
Pour distinguer quand il faut utiliser 'depuis' à la place de 'de', en type_token 13, dans par exemple "depuis le 1 janvier 2000", les sous_types D1, M1, Y1 sont utilisés pour signaler que ces mots clés sont à utiliser s'il n'y a qu'une seule date (la limite inférieure de la fourchette de dates).
La mise à jour b4.034, modifie donc la table de référence REF_TOKEN_DATE en conséquence, et la table au format texte REF_TOKEN_DATE2.txt est ajoutée au répertoire "Tables de references".
Si vous avez déjà personnalisé cette table, il est préférable de la sauvegarder par la fonction "Exporter" de la "Liste des mots clés utilisés dans les dates". Vous pourrez appliquer vos modifications à la nouvelle table, mais pour définir ou modifier SOUS_TYPE, il faudra le faire par requêtes ou par un autre outil d'accès direct à la table pour le moment...
Bons tests
André
-
...je réessayerai ce soir depuis la même config qu'essais précédents...
Après essais sur la même base 4.028 qui avait poser pb au passage 4.033, j'obtiens la fin de log suivante /*Fin des erreurs normales*/
SET ECHO OFF^
/*Passage en version 4.034
L'utilisation de la base modifiée avec une version du logiciel inférieure à V524 peut entraîner des disfonctonnements.*/
SET ECHO OFF^Suite à mise à jour avant lancement d'ancestro, dans Ref_Token_Date, on a bien ID 234 TYPE_TOKEN 24 LANGUE FRA TOKEN LIT SOUS_TYPE nullTest dans Ancestrologie:
1 - Saisie de: du 01.01.1889 à 1920
2 - Enregistrement = conversion en du 1 janvier 1889 à l'année 1920
Conclusion, ça m'a l'air bon, et je trouve ça tres "chouette" :) :D :lol: grand merci pour cette amélioration.
Mr. + me souffle à l'oreille: "ça serait super qu'en saisissant 01.01.89 ça mette 01.01.1889 en fonction du contexte, si la naissance est vers 1870 par exemple, j'avais un soft qui gérait ça tres bien il y a quelques années, mais ce n'est peut-être pas réalisabe dans les procédures, faut peut-être revoir l'exe...." on peut rêver ... :wink:
-
Mr. + me souffle à l'oreille: "ça serait super qu'en saisissant 01.01.89 ça mette 01.01.1889 en fonction du contexte, si la naissance est vers 1870 par exemple, j'avais un soft qui gérait ça tres bien il y a quelques années, mais ce n'est peut-être pas réalisabe dans les procédures, faut peut-être revoir l'exe...." on peut rêver ... :wink:
Y S'APPELLERAIT PAS M. JAMAISCONTENT TON M+? :lol:
C'est pas impossible à faire dans la procédure, mais plus compliqué car il faudrait aller chercher et analyser les autres évènements déjà enregistrés pour l'individu, les comparer avec l'évènement en cours d'enregistrement, pour connaître le siècle.
Chaque chose en son temps.
A+
André
-
Une petite question.
Je saisis un nouvel évènement 1/1/1800 : affichage après enregistrement 1 janvier 1800
OK
Une petite question.
Pour les évènements déjà saisis la date en s'inscrit par en "littéraire" et même si je ressaisis un évènement daté 1/1/1800 l'enregistrement ne se fait pas en "littéraire"
Est-ce ce qui est prévu?
-
Pour les évènements déjà saisis la date en s'inscrit par en "littéraire" et même si je ressaisis un évènement daté 1/1/1800 l'enregistrement ne se fait pas en "littéraire"
Le champ de saisie de la date n'est reanalisé que s'il est différent de la précédente chaîne de caractères. C'est pour ne pas provoquer de calculs si c'est un autre champ (le lieu par exemple) qui a été modifié. Mais il suffit d'une simple modification, comme commencer la saisie par un espace, taper 01/1/1800 au lieu de 1/1/1800 pour que le calcul se fasse.
Il y a aussi la procédure PROC_MAJ_FORME_DATE dont le fonctionnement est expliqué précédemment, qui avec les paramètes ('LIT',2) met tout à jour, même les champs de saisie de la date (date et mots clés).
A+
André
-
Cela fonctionne trés bien chez moi Merci André :wink: et, aussi d'accord avec M+ :lol:
-
Modifications mineures pour ce passage en b4.035.
A cause de M+, si on saisit "entre 01/01/1780 et 90", çà devient "entre le 1 janvier 1780 et l'année 1790". Mais je ne suis pas allé plus loin dans la conversion des années saisies avec seulement 2 chiffres. En toute logique on devrait pouvoir déduire le siècle, soit des autres évènements individuels et familiaux de l'individu, soit ceux de ses parents, soit ceux de son conjoint, soit ceux de ses enfants. Mais il devient compliqué de programmer une logique "infaillible".
J'ai aussi introduit le mois dans les critères de tri des évènements.
Dans la V525, Philippe a modifié la fiche des Mots clés utilisés dans les dates pour faire apparaître la colonne des SOUS_TYPE et les 2 lignes définissant l'ORDRE des éléments jour mois année (DMY) dans la date et la FORME (LIT, NUM ou NON) de la date saisie.
Il a aussi corrigé des problèmes de maj des tables qui m'ont permis de supprimer des contrôles par triggers ralentissant certaines fonctions.
C'est pourquoi j'ai ajouté un controle dans la mise à jour pour qu'elle ne s'exécute pas si le logiciel n'est pas au moins en v525.
A+
André