V 3.9 - Vérification des index - Restructuration d'un dossier -- Anomalies

[papo4334]

Premier et triple constat après mise à jour vers la version 3.9 (sur une généalogie de ~48 000 personnes et ce, sans avoir effectuée une seule modification de la généalogie).

• La vérification des index est nettement plus poussée qu'avec la/les version/s précédente/s , elle trouve des erreurs qui n'étaient pas détectées : avec la version 3.5 "index OK", avec la version 3.9 s'affiche un avertissement "57 erreurs trouvées"
• Restructuration du dossier généalogique (niveau 2 comme niveau complet commençant par la phase de réparation) : non seulement ne corrige pas ces erreurs, mais, pire, ajoute des erreurs d'index lors de sa première invocation . Même la réparation (qui me semble) la plus radicale Regénérer la base de donnée ne corrige pas ces erreurs d'index (nota : pas mieux avec la réparation niveau 2).
  • v3.5 : vérif. des Index OK
  • sauvegarde de la généalogie
  • passage en V3.9
  • vérif des index : 57 erreurs
  • restructuration niveau 2 (~2 minutes) -- apparait une phase "maj indexNomsPrénoms"
  • vérif. des index : 107 erreurs
  • restructuration complète (~ 4 minutes) -- apparait une phase "maj indexNomsPrénoms"
  • vérif. des index : 107 erreurs
  • réparation : regénérer (~ 10 minutes)
  • vérif. des index : 107 erreurs

En bref, la version 3.9 , détecte des erreurs, en ajoute, ne permet pas de les corriger. Il y a visiblement un grand nombre de corrections dans cette version, bravo mais malheureusement, vivement la version suivante.

Nota : on ne peut exclure que ces erreurs d'index n'en soient pas et que le bug viennent de la nouvelle implémentation de la procédure de vérification qui détecterait des erreurs imaginaires ????.

 

[papo4334]

Et cela continue ...
et prouve que au moins certains problèmes d'index (problème détectés oui, mais réels ???) ne résultent pas (directement) ni de la conversion en .gwa, ni de la migration du format 3.5 au format 3.9.

Avec l'ajout dans ma généalogie d'environ 350 personnes depuis le passage V3.9, le nombre d'erreurs détectées par la procédure "5-clics" a augmenté de 2 (passant de 110 à 112 erreurs).

Je lance ce "5-clics" à chaque fin de session et avant de sauvegarder, et j'ai observé par 2 fois cet incrément du nombre d'erreurs détectée, mais, sans aucune indication, impossible d'aller identifier parmi les 20, 30 ou 40 nouvelles fiches (de la dernière session de travail) celle qui provoque cette erreur supplémentaire.

C'est vraiment rageant, de voir ce compteur d'erreurs augmenter sans disposer de quelque moyen que ce soit pour en trouver la cause (que ce soit une vraie cause ou , plus probablement, un faux-positif qui permettrait de donner des billes au CDIP pour leur permettre de corriger le bug dans la détection des erreurs d'index).

NOTA : Depuis V3.9, en appliquant cette procédure "5-clics" je n'ai pas observé une seule fois, une étape de correction/re-génération des index, ce qui arrivait parfois avec les versions précédentes jusqu'à V3.5 notamment suite à des "fusions".

 

[predigny]

Ce qu'il faut c'est "Aucune erreur d'index" ; si vous en avez 100 il ne faut pas s'étonner que ça augmente. Le vrai problème c'est que la correction de ces erreurs soit si aléatoire. Normalement la restructuration devrait résoudre le problème d'index.

 

[papo4334]

Comme indiqué plus haut dans ce sujet, 110 premières erreurs sont apparues lors de la conversion de la base par V3.9 ; mon dernier message indiquait simplement que le nombre continue à croitre.

Rappel : aucune procédure (y compris restructuration ou même régénération de la base ou extraction de toutes les fiches dans une nouvelle base) ne change rien au nombre d'anomalies détectées. C'est d'ailleurs ce qui me conduit à penser, puisque dans ces deux cas les index sont entièrement reconstruits, qu'il ne s'agit pas d'un réel problème d'index, mais d'un bug de la procédure de vérification lorsque dans un des champs (de quelque chose dans la base, individu ou relation entre individus, lequel?) il y a une valeur qu'il interprète de travers. Ces erreurs, si elles étaient de véritables erreurs, seraient donc entièrement "fabriquées" par G2025 lui-même ; je n'y crois pas. Je n'ai, d'ailleurs, constaté aucun dysfonctionnement de G2025 v3.9 qui semble lié à ces erreurs/pseudo-erreurs d'index/

Puisque cela ne demande vraiment aucun travail (réalisable en moins de 10 minutes max), je réitère ma demande au CDIP, de fournir une version qui se contente de générer un log lors de chacune des détections d'erreurs. Cela nous/me permettra de faire le travail d'identification de la cause et de le leur transmettre.

J'imagine que c'est quelque chose aussi trivial que, par exemple, un individu qui aurait une fiche pour sa mère (connue par un parrainage d'un de ses enfants) mais aucune pour son père inconnu parce que son mariage n'est pas filiatif.

 

[jpd54]

Comme indiqué plus haut dans ce sujet, 110 premières erreurs sont apparues lors de la conversion de la base par V3.9 ; mon dernier message indiquait simplement que le nombre continue à croitre.

Rappel : aucune procédure (y compris restructuration ou même régénération de la base ou extraction de toutes les fiches dans une nouvelle base) ne change rien au nombre d'anomalies détectées. C'est d'ailleurs ce qui me conduit à penser, puisque dans ces deux cas les index sont entièrement reconstruits, qu'il ne s'agit pas d'un réel problème d'index, mais d'un bug de la procédure de vérification lorsque dans un des champs (de quelque chose dans la base, individu ou relation entre individus, lequel?) il y a une valeur qu'il interprète de travers. Ces erreurs, si elles étaient de véritables erreurs, seraient donc entièrement "fabriquées" par G2025 lui-même ; je n'y crois pas. Je n'ai, d'ailleurs, constaté aucun dysfonctionnement de G2025 v3.9 qui semble lié à ces erreurs/pseudo-erreurs d'index/

Puisque cela ne demande vraiment aucun travail (réalisable en moins de 10 minutes max), je réitère ma demande au CDIP, de fournir une version qui se contente de générer un log lors de chacune des détections d'erreurs. Cela nous/me permettra de faire le travail d'identification de la cause et de le leur transmettre.

J'imagine que c'est quelque chose aussi trivial que, par exemple, un individu qui aurait une fiche pour sa mère (connue par un parrainage d'un de ses enfants) mais aucune pour son père inconnu parce que son mariage n'est pas filiatif.

Bonjour,

J’ai une base d’environ 110 000 personnes qui semble fonctionner normalement

Le test des 5 clics m’indique : aucune erreur d’index

Par contre si j’effectue une restructuration de niveau 2 , le même test m’indique 21 erreurs d’index

De même si j’effectue une extraction totale (à partir de la base « saine »), j’ai également 21 erreurs

Dans les 2 cas je n’arrive pas à les faire disparaître

J’utilise Généatique depuis plus de 30 ans, je n’ai jamais connu de tes problèmes

Si quelqu’un a une solution, je suis preneur

 

[papo4334]

Bonjour,

J’ai une base d’environ 110 000 personnes qui semble fonctionner normalement

Le test des 5 clics m’indique : aucune erreur d’index

Par contre si j’effectue une restructuration de niveau 2 , le même test m’indique 21 erreurs d’index

De même si j’effectue une extraction totale (à partir de la base « saine »), j’ai également 21 erreurs

Un grand merci pour le témoignage.

Cela démontre plusieurs choses :

• 1. je ne suis pas le seul ; plus exactement ma généalogie n'est pas la seule pour laquelle des erreurs d'index plus ou moins "bidons" sont répertoriées par la procédure "5-clics".
• 2. c'est un comble que, chez vous, ce soient les procédures de réparation/re-génération qui fassent apparaitre ces erreurs et qu'ensuite rien ne permette de les corriger
• 3. confirmation que ces erreurs sont le résultat d'une incohérence entre la base générée par G2025 V3.9 (restructuration, re-génération) et la procédure de contrôle des index.

AMHA, nous ne devons pas trop nous inquiéter pour la majorité de ces problèmes d'index.

Cependant, le CDIP doit vraiment se pencher sur ce problème qui, au passage, masque d'éventuels véritables problèmes d'index.

 

[predigny]

...
Cependant, le CDIP doit vraiment se pencher sur ce problème qui, au passage, masque d'éventuels véritables problèmes d'index.

Tout à fait d'accord.