Auteur Sujet: Base b4.009, essais [TERMINES] à suivre sur b4.010  (Lu 16316 fois)

plus minus reset

0 Membres et 1 Invité sur ce sujet

Hors ligne DDdeBerdeux

Base b4.009, essais [TERMINES] à suivre sur b4.010
« le: 11 Décembre 2005 à 18:09:40 »
C'est bientôt Noël, alors je vous ai fait un petit cadeau, le passage de la base en version b4.009. Evidemment, pas de confusion, il ne s'agit encore que d'une version en test. Donc prenez bien les précautions d'usage en particulier pour sauvegarder vos données avant d'exécuter le fichier maj_b357_b4009.exe. Et si çà marche correctement, j'espère que celà contribuera à une prochaine version, officialisée par Philippe CM.

L'exécutable de mise à jour est à télécharger maj_b357_b4009.exe

Le fichier FAMILLEVIDE4009.zip contient la base vide et le fichier modificationsBDD.txt expliquant toutes les modifications effectuées depuis la version b3.57.



Pour éviter les confusions, je souhaiterai que les liens vers les fichiers téléchargeables restent sur ce forum, afin que les personnes qui téléchargent ne puissent pas le faire sans avoir la possibilité de lire ces avertissements.



Les modifications effectuées depuis la b4.004 téléchargeable sur le site ancestrologie.org sont les suivantes:



Modifications PROC_INCOHERENCES pour ajouter les controles évènements individuels absents dans T_ASSOCIATIONS, et des évènements familiaux sans union, unions avec conjoint à 0 ou null.



Ajout à la table REF_RELA_TEMOINS de 2 colonnes pour mémoriser les tag-témoins anciens et nouveaux, et d'une procédure PROC_REF_TEMOINS(A ou N) pour choisir les tag-témoins à utiliser avant et après l'importation d'un gedcom



Modification de la table de référence des évènements pour remplacer TITR non gedcom et non récupéré par ancestrologie, par TITL. Mise à jour de la table EVENEMENTS_IND en conséquence.

Ajout dans la procédure de mise à jour  des fichiers REF_EVENEMENTS2.txt, REF_DEPARTEMENTS2.txt et REF_RELA_TEMOINS2.txt mis à jour suite aux modifications sur les tables de références. Noms avec indice 2 pour ne pas écraser des tables de références éventuellement modifiées par les utilisateurs.



Pour correction des statistiques sur le dossier ("Informations") modification des procédures PROC_COMPTAGE et PROC_COMPTE_VILLES.



Correction de PROC_ETAT_AGE_PREM_UNION_BASE et des états age_premiere_union.rtm et age_premiere_union_orange.rtm pour le fonctionnement de ces états.



Corrections pour présentation (étiquettes de colonnes se chevauchant) des états de dénombrement de descendance.



Modifications pour introduire les calculs de consanguinité et de parenté

Création d'une table temporaire TQ_CONSANG,

Création d'une procédure récursive PROC_CONSANG de calcul de la parenté entre 2 individus ou de consanguinité d'un individu selon le mode utilisé, selon la formule de Malecot,

Modifications de PROC_ETAT_DENOMB_ASCEND et des états de dénombrement d'ascendance pour faire apparaître la consanguinité

Création d'une procédure PROC_PARENTE utilisable depuis le BOA pour calculer la parenté entre 2 individus.



Le petit cadeau de Noël c'est le calcul du coefficient de consanguinité d'un individu et le calcul du coefficient de parenté entre deux individus (enfin, si je ne me suis pas planté dans les calculs et je compte sur vous pour me le dire).

Ce calcul fait suite à un petit défi de Lya qui m'a donné un lien vers le site http://baudetdupoitou.online.fr/annexes/annexe2.htm expliquant la formule de Malécot. Si la formule est bonne pour des ânes, elle doit l'être aussi pour nous :lol:

Le coefficient de consanguinité est affiché sur l'état de dénombrement d'ascendance au niveau de la génération 1 en dernière colonne à droite.

Pour obtenir le coefficient de parenté entre 2 individus il faut exécuter la requête SELECT * FROM PROC_PARENTE( CLE_INDIVIDU1 , CLE_INDIVIDU2 )dans le BOA (ou un autre requêteur) en attendant qu'un jour Philippe CM nous fasse une interface plus conviviale depuis le menu Individu par exemple (c'est une suggestion).



Un point IMPORTANT à noter par les testeurs: les modifications pour corriger les statistiques de villes par pays du dossier atteintes depuis le petit bouton "Détail" de la fenêtre "Mes généalogies" / "Informations", ont mis en évidence une anomalie de verrouillage de table temporaire, que Philippe a bien identifiée et corrigée pour la prochaine version du logiciel (v394 ou plus). En attendant qu'il la mette en ligne, si vous avez touché à ce petit bouton "Détail", il est préférable de quitter Ancestrologie avant d'y revenir. Sans celà vous ne pourriez pas revoir les "Informations" et il y a peut-être d'autres fonctions que j'ignore qui ne fonctionneront pas.



Autre point à retenir: avant de s'exécuter la procédure de mise à jour présente des messages, qu'il est important de lire au moins une fois. Au cours de son exécution, un "jounal" modifbase.log est enregistré dans le répertoire d'ancestrologie. Il y figure des renseignements divers sur la mise jour et son déroulement. Les messages d'erreurs du type "trigger ou procédure existe déjà", "table non trouvée" ...(en anglais malheureusement) ne sont pas graves et sont souvent provoqués parce que la base a déjà été mise à jour au moins partiellement. Il n'y a pas d'inconvénient, bien que celà soit inutile, à exécuter plusieurs fois la mise à jour sur la même base.



Si vous avez plusieurs bases, il est nécessaire d'appliquer la procédure de mise à jour pour chacune d'elles.



Si certains ont personnalisés des états modifiés au cours de cette procédure (voir ci-dessus, mais çà m'étonnerait vu qu'ils ne fonctionnaient pas ou mal), il est préférable qu'ils en sauvegardent les fichiers ou les renomment, pour éviter qu'ils soient écrasés.



Le fichier famillevide.bdd est surtout destiné à ceux qui préfèrent utiliser une base par généalogie plutôt que des dossiers, pour des raison de sécurité et de rapidité. J'en suis. Il ne contient que les tables de références, et est ainsi prêt à recevoir votre premier dossier.



S'il y a diverses questions qui se posent sur cette version, il est préférable de ne pas les dispercer, et de toutes les mettres sur ce fil.

J'essayerai de mettre dans ce message les principales réponses comme celle-ci expliquant les raisons possibles de messages d'erreurs pendant l'exécution de la procédure de mise à jour, et leurs remèdes:



maj_b357_b4009.exe est un fichier exécutable qui est à télécharger en cliquant sur le lien du message, sur le bureau de windows par exemple. Ensuite en double cliquant sur le fichier téléchargé, il s'exécute et met à jour la base en cours dans Ancestrologie (que l'on aura pris soin de quitter auparavant, FireBird embedded mono-utilisateur oblige).

Pendant la mise à jour on peut voir apparaitre une fenêtre en ligne de commande. Certains peuvent y voir apparaître un message d'erreur signalant l'absence du fichier gds32.dll. Ce message est normal et sans conséquence pour ceux qui utilisent FireBird v1.5x en version serveur. C'est parce que l'exécutable de mise à jour a besoin de fbclient.dll. Donc pour ceux qui utilise FB embedded, le gds32.dll qui se trouve dans le répertoire d'Ancestrologie est renommé provisoirement fbclient.dll. S'il ne le trouve pas, le message d'erreur est émis dans la fenêtre en mode commande, mais c'est normalement sans conséquence, puisque l'absence de ce gds32 signifie que c'est alors une version serveur qui est utilisée. FB serveur en v1.5x place fbclient.dll et gds32.dll dans le répertoire system32 situé dans le path, donc la procédure de maj le trouvera toute seule.

Le seul problème peut-être pour ceux qui utiliseraient encore la première version serveur de FB v1.0 ou Interbase serveur. Ces versions n'installaient que gds32.dll dans system32. Le remède: faire une copie de gds32.dll dans le même répertoire et la renommer fbclient.dll. Ou supprimer ce serveur et le remplacer par FB v1.53 librement téléchargeable sur internet, comme là http://www.ancestrologie.org/forum/index.php?topic=4776.0&postdays=0&postorder=asc&start=4



Bon Noël :wink:

André



Mise à jour des fichiers le 12/12/2005 à 22h00. Description des modifications http://www.ancestrologie.org/forum/index.php?topic=5123.0&postdays=0&postorder=asc&start=16

Télécharger et exécuter la nouvelle version du fichier maj_b357_b4009.exe pour mettre à jour la base.
Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée. (Loi des Mises à Jour)
 

Hors ligne Claude Baudin

  • AncestroSenior
  • *****
  • Messages: 1 709
Base b4.009, essais [TERMINES] à suivre sur b4.010
« Réponse #1 le: 11 Décembre 2005 à 19:25:31 »
Installation réussie

Je ne sais si cela se revele depuis cette version mais le tri n'a plus l'air de fonctionner de façon automatique  :oops:
Cordialement
A+
Ancestrologie V 1101 B 5122
PIV 3G° 2048 M°
Intel core 2 duo, 2048M° Ecran 19p et 17p
OS Vista  Windows7 et Xp
___________

Claude
 

Hors ligne Claude Baudin

  • AncestroSenior
  • *****
  • Messages: 1 709
Base b4.009, essais [TERMINES] à suivre sur b4.010
« Réponse #2 le: 11 Décembre 2005 à 19:32:02 »
Ne pas tenir compte de mon message précédent, cela fonctionne a condition de se conformer a la saisie des dates  :wink:
Cordialement
A+
Ancestrologie V 1101 B 5122
PIV 3G° 2048 M°
Intel core 2 duo, 2048M° Ecran 19p et 17p
OS Vista  Windows7 et Xp
___________

Claude
 

garnierfrancoise

  • Invité
Base b4.009, essais [TERMINES] à suivre sur b4.010
« Réponse #3 le: 11 Décembre 2005 à 20:17:00 »
Je n'ai pas eu de problèmes d'installation.

J'ai apprécié l'amélioration des informations et des statistiques.



Seule remarque:

Pour un dossier mon sosa a des implexes et sa consanguinité n'est pas nulle (OK)

Pour un autre dossier le sosa a un implexe de 0,51 % à la dixième génération et une consanguinité nulle (je m'attendais à une consanguinité non nulle mais c'est peut-être dû à un arrondi si elle est inférieure à 0,0099 ?)



Cela dit Merci André pour ton travail. Salutations normandes à un autre armoricain
 

Hors ligne DDdeBerdeux

Base b4.009, essais [TERMINES] à suivre sur b4.010
« Réponse #4 le: 11 Décembre 2005 à 20:40:04 »
Citation de: "garnierfrancoise"
Pour un dossier mon sosa a des implexes et sa consanguinité n'est pas nulle (OK)

Pour un autre dossier le sosa a un implexe de 0,51 % à la dixième génération et une consanguinité nulle (je m'attendais à une consanguinité non nulle mais c'est peut-être dû à un arrondi si elle est inférieure à 0,0099 ?)
La grosse différence entre un calcul d'implexe et un calcul de consanguinité, c'est que ce dernier donne une importance plus grande aux ancêtres communs proches, qu'aux lointains, ce qui semble logique. Dans les essais que je peux faire sur ma généalogie, s'il n'y a pas d'implexe dans les 5 premières générations, la consanguinité doit être si faible (<0,00005 dans l'absolu) que c'est 0 qui s'affiche.

Mais j'avoue que je n'ai pas le courage de refaire les calculs à la main pour vérifier. Alors s'il y a des fanatiques de l'arithmétique qui ont ce courage...

Ou bien comparer avec le résultat que donnent certains sites. On m'a dit que généanet faisait ce calcul. Encore faut-il avoir mis sa généalogie sur généanet pour comparer avec ce que donne Ancestro! Et j'ignore la méthode utilisée par généanet. Je me méfie toujours, on trouve tellement de bêtises sur internet! Je ne sais plus si je l'ai dit ici, mais j'ai même vu certain trouver un nombre d'ancêtres théorique impair!

A+

André
Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée. (Loi des Mises à Jour)
 

garnierfrancoise

  • Invité
Base b4.009, essais [TERMINES] à suivre sur b4.010
« Réponse #5 le: 11 Décembre 2005 à 21:28:02 »
Citation de: "DDdeberdeux"
Je ne sais plus si je l'ai dit ici, mais j'ai même vu certain trouver un nombre d'ancêtres théorique impair!





Oui tu l'avais déjà dit :roll:



Je suis d'accord avec ton commentaire et ton travail me satisfait entierement
 

Hors ligne DDdeBerdeux

Base b4.009, essais [TERMINES] à suivre sur b4.010
« Réponse #6 le: 11 Décembre 2005 à 23:58:48 »
Citation de: "garnierfrancoise"
Oui tu l'avais déjà dit :roll:
Je dois commencer à radoter :oops:

Bonne nuit

André
Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée. (Loi des Mises à Jour)
 

Hors ligne Roger 1

  • AncestroExpert
  • *****
  • Messages: 627
Base b4.009, essais [TERMINES] à suivre sur b4.010
« Réponse #7 le: 12 Décembre 2005 à 10:18:59 »
Beau travail, André, tu peux te reposer un peu sur tes lauriers, en attendant les fêtes. Dans le dénombrement ascendance, je vois l'ensemble de mes générations alors que précedemment je n'en voyait que trente. Juste une suggestion, que j'avais placé sur le forum du même nom. Serait-il possible d'utiliser l'état dénombrement d'ascendance sans qu'il se référe systématiquement à l'individu de la fiche, à l'instar d'autres états, avoir une boîte de dialogue avec affichage du répertoire, ou autre.

Je m'aperçois, que je te dis, que tu peux te reposer, et à la du message je t'incite  à réfléchir.  :lol:

A+
 

Hors ligne Facon

Base b4.009, essais [TERMINES] à suivre sur b4.010
« Réponse #8 le: 12 Décembre 2005 à 11:10:58 »
Bonjour André,



Les résultats du test sont les suivants:

-Configuration XP Home sp2

-Ancestrologie départ: v391 b4.005

-Base de 9000 individus env. répartis sur 15 dossiers dont un de 6000 individus env.

-Ancestrlogie arrivée: v391 b4.009



La màj de la base s'est déroulée sans problème.



Constats:

1. Mes Généalogies/Informations: Les infos géographiques semblent être crédibles.

2. L'activation du bouton détail est bien bloquant. Retour à une situation normale avec le redémarrage d'Ancestrologie.

3.Documents/Statistiques/Patronymes: RAS

4.Documents/Statistiques/Prénoms: RAS, seul le premier prénom a la première lettre en majuscule, ce n'est pas génant pour moi et c'était déjà ainsi avec l'ancienne structure de base.

5.Documents/Statistiques/Age à la première union: La tableau est maintenant renseigné avec pour les hommes et les femmes (nombre et age moyen). Dans la version initiale seule la colonne Hommes (nombre) était renseigné. L'affichage des informations commence en 1900, il y a cependant de nombreuses unions renseignées avant cette date.

6.Documents/Statistique/Longévité: RAS,

7.Documents/Statistiques/Nombre d'enfants par union: RAS,

8.Documents/Statistiques/Recensement: RAS,

9.Documents/Statistiques/Dénombrement ascendance: La colonne consanguinité apparaît bien. Avec les données de ma base: implexe 0 et consanguinité 0, ce qui semble être correct.

10.Documents/Statistiques/Dénombrement descendance: RAS,

11.Documents/Statistiques/Graphique par Pays ou Départements: Il n'y a plus la litanies de tous les départements et les naissances ou décès par département ou pays semblent être crédibles. Dans mon cas, le département du Nord apparaît deux fois avec le même nombre aussi bien pour les naissances que pour les décès par département, c'est nouveau par rapport à la structure de base initiale. Près de 3000 naissances et 1400 décès pour le Nord où se tient l'essentiel de ma généalogie (le gros dossier). Les listes des naissances et décès par départements comportent une première ligne sans indication de département mais avec un nombre, même chose pour la dernière ligne. Les listes par pays ont aussi une dernière ligne sans nom de pays. Enfin et ce n'est pas grave, ces listes par départements gagneraient à être établies par pays puis départements. Ce n'est pas une demande.



En conclusion, vu d'ici seuls les points 5 et 11 méritent une explication et éventuellement une retouche sauf si l'anomalie provient de mes données.



Depuis le passage de b3.57 à b4.00x j'ai remarqué qu'il fallait un peu plus de temps pour un changement de fiche et notamment à l'occasion du retour répertoire vers fiche.



Merci André pour ce bon travail.
Christian
 

Hors ligne DDdeBerdeux

Base b4.009, essais [TERMINES] à suivre sur b4.010
« Réponse #9 le: 12 Décembre 2005 à 11:23:12 »
J'approuve ta suggestion. J'y ai ajouté un petit commentaire pour la généraliser, avec un petit bémol pour rappeler la priorité aux corrections de bugs.

Je viens de faire un petit test pour vérifier que le calcul de parenté n'était pas totalement faux, par la requête SELECT * FROM PROC_PARENTE(14,307). J'ai obtenu un coefficient de parenté de 0,287 ce qui est normal puisque 14 et 307 son frére et soeur (parenté 0,25) et qu'en plus leurs parents doivent être cousins.

A+

André
Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée. (Loi des Mises à Jour)
 

Hors ligne Claude Baudin

  • AncestroSenior
  • *****
  • Messages: 1 709
Base b4.009, essais [TERMINES] à suivre sur b4.010
« Réponse #10 le: 12 Décembre 2005 à 11:45:37 »
Chez moi en ce qui concerne le bouton detail du point 2 ne bloque pas ancestrologie  :wink:
Cordialement
A+
Ancestrologie V 1101 B 5122
PIV 3G° 2048 M°
Intel core 2 duo, 2048M° Ecran 19p et 17p
OS Vista  Windows7 et Xp
___________

Claude
 

Hors ligne Facon

Base b4.009, essais [TERMINES] à suivre sur b4.010
« Réponse #11 le: 12 Décembre 2005 à 12:07:44 »
Bonjour,



Le passage par Mes Généalogies/Informations permet de lire le ....informations. L'activation du bouton détail fait apparaître un graphique.



Après la fermeture de cette fenêtre puis de la fenêtre informations il n'est plus possible de relire les informations sans avoir redémarré Ancestrologie.
Christian
 

Hors ligne DDdeBerdeux

Base b4.009, essais [TERMINES] à suivre sur b4.010
« Réponse #12 le: 12 Décembre 2005 à 12:21:50 »
Re Bonjour,

Ma précédente réponse était pour Roger, mais le message de Christian est venu s'immiscer entre les deux.

Merci pour tes essais.

Pour le point 5, j'ai trouvé la raison du problème. Je ne faisais la sélection que sur le dossier 1, et je ne m'en suis pas aperçu en testant parce que je n'utilise qu'un dossier par base. Je corrige çà, ensuite je vais modifier le fichier de mise à jour en mettant un petit PS: en bas de mon premier message. Quand ce sera fait il suffira de réexécuter le fichier de maj.

Pour le point 11, je pensais le problème règlé pour le département du Nord. L'origine de ce pb, c'est que dans la table de référence REF_DEPARTEMENTS "Nord" apparaît 2 fois, la 2ième étant pour le département du Nord de la Nouvelle Calédonie. Lors de la procédure de mise à jour je passe donc la requêteUPDATE REF_DEPARTEMENTS SET RDP_LIBELLE = 'Nouvelle Calédonie du Nord' WHERE RDP_CODE = 9881;

UPDATE REF_DEPARTEMENTS SET RDP_LIBELLE = 'Nouvelle Calédonie du Sud' WHERE RDP_CODE = 9882;
pour corriger çà. Est-ce que par hasard tu n'aurais pas une table différente où les RDP_CODE ne seraient pas les mêmes? Essaies de visualiser le contenu de la table avec la requêteSELECT * FROM REF_DEPARTEMENTS where RDP_LIBELLE='Nord'dans le BOA, pour voir si tu as encore 2 départements du Nord. Et si tu y trouves le 9881, repasse la première requête. Cà voudrait dire que cette première requête ne s'est pas exécuter lors de la maj.

Pour les lignes sans nom, il y a 2 cas: si le pays est laissé sur NULL, il apparaît une ligne en fin de liste

si le pays est un caractère espace ou une chaîne vide, il paraît en fin.

J'attend ta conclusion sur le pb de département pour passer un correctif.

Merci et bon appétit

André
Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée. (Loi des Mises à Jour)
 

Hors ligne Facon

Base b4.009, essais [TERMINES] à suivre sur b4.010
« Réponse #13 le: 12 Décembre 2005 à 12:57:11 »
Re bonjour,



La requète de recherche de libellé retourne effectivement:



1;59;Nord;31;1;59 et

2;9881;Nord;988;98000



La mise en oeuvre via BOA de la première requète destinée à revenir à "Nouvelle Calédonie du Nord" retourne l'erreur:



Violation d'accès à l'adresse 0D66B088 dans le module 'DLL_BOA.dll'. Ecriture de l'adresse 00000000. J'ai quitté BOA en validant les modifications.



Dans Documents/Graphiques...... j'ai bien perdu le Nord...... de la Nouvelle Calédonie. Il n'y a plus qu'un seul Nord.

La table REF_DEPARTEMENTS est toujours avec la ligne 9881;Nord;988;98000.



Pour info, je travaillais effectivement sur le dossier n°2, j'utilise BOA v1.7



Merci pour cette intervention rapide.
Christian
 

Hors ligne DDdeBerdeux

Base b4.009, essais [TERMINES] à suivre sur b4.010
« Réponse #14 le: 12 Décembre 2005 à 13:29:34 »
Philippe CM vient de mettre en ligne une version v395 du logiciel.

Elle corrige:

Le blocage de la table provisoire qui touchait l'affichage des informations du pays dont je vous parlais précédemment.

Un message "MP_TABLE doit avoir une valeur" qui apparaissait dans la fenêtre "La Médiathèque" (menu configuration / bibliothèque multimédia) quand on double cliquait sur une image réduite.

Et surtout, le problème des témoins qui ne s'affichaient pas ou plutot qui étaient enregistrés avec un mauvais code_fiche.



Pour Christian, je suppose que c'est dans la table de référence en mode texte REF_DEPARTEMENTS.txt dans le répertoire \tables de references que tu as trouvé la ligne 9881;Nord;988;98000? Par contre tu devrais trouver dans le même répertoire un fichier REF_DEPARTEMENTS2.txt où cette ligne est corrigée. Je n'ai pas donné exactement les mêmes noms aux fichiers de référence que je modifie (comme pour les évènements et les témoins), parce que certains utilisateurs ont "personnalisés" ces fichiers. Si çà n'est pas ton cas, tu peux supprimer l'ancien et enlever le 2 du nom du nouveau. Si non, il faut corriger manuellement l'ancien fichier .txt, en suivant bien le modèle donné dans le nouveau (mais il n'y a que le fichier des témoins qui a 2 colonnes de plus). Mais ces fichiers ne sont utilisés que pour recharger les tables de référence.

Je regarde quand même pourquoi la table REF_DEPARTEMENTS n'a pas été mise à jour chez toi.

A+

André
Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée. (Loi des Mises à Jour)
 

Hors ligne Facon

Base b4.009, essais [TERMINES] à suivre sur b4.010
« Réponse #15 le: 12 Décembre 2005 à 14:07:16 »
André,

Affirmatif, la ligne 9881;Nord;988;98000 provient bien du fichier texte REF_DEPARTEMENTS.

Je ne l'avais pas cité, mais lors de la mise à jour de la base il y a bien eu création des trois fichiers indexés 2 dans le répertoire des tables de références.

Pour ta gouverne mais c'est avec moins de conséquence pour moi, la ligne 9882 n'a pas été rebaptisé Nouvelle Calédonie du Sud dans le fichier REF_DEPARTEMENTS non indexé.

En tous cas, tout à l'heure, le repassage de la requète pour modifier le libellé 'Nord' a bien été suivi d'effet au niveau de la base et l'affichage de la liste des lieux fait bien apparaître Nouvelle Calédonie du Nord et Nouvelle Calédonie du Sud.
Christian
 

Hors ligne DDdeBerdeux

Base b4.009, essais [TERMINES] à suivre sur b4.010
« Réponse #16 le: 12 Décembre 2005 à 17:40:06 »
Bonsoir,

Cà y est j'ai modifié les fichiers maj_b357_b4009.exe et FAMILLEVIDE4009.zip en ligne (je ne fais pas de changement de version pendant cette phase de test), pour tenir compte de vos remarques jusqu'à présent.

Correction de l'erreur de dossier dans la procédure PROC_ETAT_AGE_PREMIERE_UNION utilisée par l'état des âge à la première union.

Correction des procédures PROC_COMPTAGE et PROC_COMPTE_VILLES pour ignorer les différences d'écriture en majuscules/minuscules, espaces avant ou après les noms, chaîne vide ou NULL dans les statistiques du dossier affichées dans la fenêtre "informations" et détail.

Corrections identiques pour la procédure PROC_STATISTIQUES, sauf la distinction chaîne vide ou NULL impossible à mettre en oeuvre simplement. Regroupement des départements par pays. Cette procédure est utilisée par les états statistiques par pays et départements, ainsi que par le module statistiques complémentaires. A noter que les modifications de cette procédure induisent une très nette augmentation de son temps d'exécution.

A+

André

PS: re modif à 22h00 de PROC_STATISTIQUES trop lent: uniquement tri primaire par pays conservé.
Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée. (Loi des Mises à Jour)
 

Hors ligne Horemans

  • AncestroSenior
  • *****
  • Messages: 1 775
    • http://perso.wanadoo.fr/philippe.horemans
Base b4.009, essais [TERMINES] à suivre sur b4.010
« Réponse #17 le: 12 Décembre 2005 à 20:03:34 »
Citation de: "DDdeberdeux"
A noter que les modifications de cette procédure induisent une très nette augmentation de son temps d'exécution.


Au point qu'on se demande si tout se passe bien  :!:

Petit problème en ce qui me concerne :

Pour les Naissances par dépt, la fenêtre affiche 10 lignes de 4 colonnes soit 40 départements

Pour les décès par dépt, la fenêtre affiche 10 lignes de 5 colonnes.

Mes ancêtres ayant beaucoup migré dans les départements français et les provinces belges, je n'ai pas mon compte

La manche (50) est en 40ème position, c'est dire que je n'ai pas beaucoup de trous dans la liste.
Plus çà va, plus je me régale...  Et avec  Quisontils, la gestion des actes, c'est facile !   Philippe
 

Hors ligne DDdeBerdeux

Base b4.009, essais [TERMINES] à suivre sur b4.010
« Réponse #18 le: 12 Décembre 2005 à 20:51:45 »
Bonsoir,

Citation de: "Horemans"
Citation de: "DDdeberdeux"
A noter que les modifications de cette procédure induisent une très nette augmentation de son temps d'exécution.


Au point qu'on se demande si tout se passe bien  :!:
Au point que je me demande si je ne vais pas revenir en arrière sur ce point. Les dernières modifications étaient surtout pour éviter de déclarer un autre département si par hasard il avait été mal saisi, espaces devant ou derrière, majuscule ou minuscule différents de la table de réference. Je vois que çà coûte trop de temps. Et normalement çà devrait être saisi avec la table de réference.

Votre avis?

Pour le reste, tu parles bien des états? pas du module complémentaire?

Parce que je n'ai pas modifié l'état. Chez moi le fichier Stat_Graph_naiss_dept.rtm date du 25/08/2001 et n'a que 2 colonnes: le nom du département (ou du pays) et le nombre d'évènements. Il n'aurait pas été modifié chez toi?

A+

André
Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée. (Loi des Mises à Jour)
 

Hors ligne Horemans

  • AncestroSenior
  • *****
  • Messages: 1 775
    • http://perso.wanadoo.fr/philippe.horemans
Base b4.009, essais [TERMINES] à suivre sur b4.010
« Réponse #19 le: 12 Décembre 2005 à 21:39:34 »
Je pense aussi qu'il faur alléger les contrôles à ce niveau pour ganer en temps de réponse.

Comme tu le dis, en principe, personne ne saisit manuellement le département si on utilise correctement la table des villes. Il ne doit donc y avoir qu'exceptionnellement des fautes de frappe, et les moyens manuels de contrôle doivent suffir (lecture des listes rapports etc...)



Citation de: "DDdeberdeux"
Pour le reste, tu parles bien des états? pas du module complémentaire?


Je parle effectivement du module complémentaire qui affiche maintenant des choses sensées alors qu'avant, tout le Hainaut (Belgique) se retrouvait comptabilisé dans le Calvados.

çà restera donc à améliorer.



Je vais regarder maintenant ce que donnent les implexes et cousinages
Plus çà va, plus je me régale...  Et avec  Quisontils, la gestion des actes, c'est facile !   Philippe