Sujet: [Résolu] Blocage lors du calcul de consanguinité

[Joël AUGUSTE]

Bonsoir,



J'ai Ancestrologie V420 b4.010.

Dans ma base, j'ai 2 dossiers : 1 de 2.300 individus et 1 autre de 13.100.

J'avais déjà fait un calcul de consanguinite avec le dossier de 2.300 individus sans aucun problème (avec une version précédente à la 420).

Je viens d'essayer de faire le calcul avec le dossier de 13.100... J'attends, mais c'est normal avec 13.100 bonhommes... Le gestionnaire de tâches me dit UC à 100%... En allant voir dans applications du gestionnaire, je m'aperçois que le programme ne répond plus... Je ferme, je recommence, le programme ne répond plus au bout de quelques secondes.

Même essai avec la base de 2.300 (celle qui a déjà eu un calcul de consanguinité avec une version précédente) et au bout de 2 secondes : le programme ne répond plus !



Cordialement



Joël

[Bruno T.]

Je viens d'essayer de faire le calcul avec le dossier de 13.100... J'attends, mais c'est normal avec 13.100 bonhommes... Le gestionnaire de tâches me dit UC à 100%... En allant voir dans applications du gestionnaire, je m'aperçois que le programme ne répond plus...

Il n'a peut-être pas le temps ...si il travaille

Je ferme, je recommence, le programme ne répond plus au bout de quelques secondes.

As-tu vraiment attendu longtemps ?

N'ayant pas d'indicateur, c'est pas facile de savoir si ca travaille ou si c'est planté.

[Joël AUGUSTE]

Je pensais que lorsque le gestionnaire de tâches indiquait : "pas de réponse", cela signifiait que le programme était bloqué !  

Je suis en train de refaire l'essai avec la base de 2.300 individus, au bout de 2 minutes, j'ai toujours l'UC à 100% et l'indication "pas de réponse". Lors du 1er calcul, j'avais obtenu le résultat en une dizaine de secondes environ...

J'ai Windows XP SP2 Athlon 3200+ et 512 Mo de RAM

Voilà... calcul terminé au bout de 3 minutes environ

Je vais m'armer de patience et laisser travailler avec le dossier de 13.100 individus... Je vous ferai part de mes conclusions...



Cordialement



Joël

[DDdeBerdeux]

En général, après un calcul de consanguinité, la base a augmenté de taille. Il est donc préférable de refaire une optimisation.

Mais il est très dangereux d'arrêter le calcul par le gestionnaire de tâches, il y a de gros risques de corruption de la base de données. Ce n'est pas l'arrêt d'Ancestrologie qui est dangereux, mais celui de Firebird qui continu les calculs, même quand Ancestrologie est arrêté. Il est possible que pendant la durée du calcul, Ancestrologie ne réponde pas parce qu'il attend Firebird (d'où le message "pas de réponse").

Je crois que Roger1 a fait des essais sur une base de cette ampleur, dans un délais raisonnable.

A+

André

[Joël AUGUSTE]

Bonjour,



Merci André pour l'info du risque de corruption de la base, j'avais fait une sauvegarde de la base avant.

Pour info, j'avais fait une optimisation de base avant...

Ignorant ton avertissement, j'ai arrêté encore une fois Ancestrologie par le gestionnaire de tâches après 3h10 de calcul, UC à 100%... Ben oui, il était 00h50...

Je viens de regarder la taille de ma base, elle a effectivement presque doublé de volume, elle est passée de 37.000 Ko à 68.000.

Ce matin, impossible de rouvrir Ancestrologie, j'ai le message : "internal gds software consistency check (can't continue after bugcheck)". J'ai été obligé de remettre ma sauvegarde... Ouf, a priori ça tourne normalement !!! Donc ton info de gros risque de corruption s'est avérée exact !

Il est à noter que les deux premières fois je n'avais pas eu de message de bug, il est vrai que j'avais arrêté Ancestrologie après seulement 3/4 minutes de calculs. Il y a-t'il relation de cause à effet ?

Ceci dit, avec Windows XP SP2 Athlon 3200+ et 512 Mo de RAM, plus de 3h10 de calculs, ça me semble plutôt long pour un fichier de 13.000 individus... D'autant plus qu'avec une UC à 100%, il n'y avait qu'Ancestrologie d'ouvert ! Dois-je recommencer l'expérience en laissant le pc tourner toute une nuit ?



Cordialement



Joël

[DDdeBerdeux]

Bonjour,

Ton expérience me permet de rappeler encore une fois les risques qu'il y a à utiliser plusieurs dossiers dans la même base.

Elle est aussi la démonstration que l'arrêt au bout de 3/4 de minute a corrompu la base au point que le calcul s'est avéré impossible par la suite.

Des incidents de ce type me sont arrivés plusieures fois, à la suite d'erreurs de programmation, quand je mettais au point ce calcul. Mais utilisant la version serveur de Firebird et IBOConsole, je dispose d'une fonction de validation de la base qui m'a presque toujours permi de la nettoyer. Je ne pense pas que cette fonction soit accessible avec la version embedded.

Sur un poste à peine plus puissant que le tien (3500+, 1GoRAM), il faut environ 9s pour une base (1 seul dossier) de également 2300 individus.

On pourrait estimer à 6 fois plus soit 1mn le temps de calcul pour ta base de 13000 individus. Mais il ne faut pas ignorer que cette durée peut être très variable selon le nombre d'implexes dans le dossier. Pour la base des rois de France de 1512 individus, il faut plus de 8s.

Le calcul enchaîné à la renumérotation sosa, est évidemment moins longue, mais pas en proportion. Les "sosa" sont en général la lignée à laquelle on s'intéresse, donc étant beaucoup plus documentée, on y a plus de chance de rencontrer des implexes.

A+

André

[AquaBlue]

Je viens de tester et j'ai le même problème que Joël.



Base de test de 18000 personnes et le calcul ne se termine pas.

Au bout de 10 minutes j'ai tué la tache.

V420 base 4.010

Athlon 64 3000+ 1Go RAM

Firebird 1.5.1.4481

[Pierrot]

Base de test de 4.500 personnes et le calcul ne se termine pas.

Au bout de 45 minutes j'ai tué la tache.

V420 base 4.010

[DDdeBerdeux]

Est-ce que l'un d'entre vous pourrait me dire en mp où télécharger sa base pour que j'étudie le problème?

Et me dire si çà passe avec le calcul limité aux sosa.

A+

André

[Joël AUGUSTE]

Bonsoir,



Je viens de faire un essai en faisant le calcul de consanguinité limité aux sosas.

Premier problème : où ça se trouve ? ... Bon après avoir cherché partout sans le trouver, j'ai refait un calcul des sosas... et miracle, la question est arrivée à la fin...  

Avec le fichier de 2.300 individus, résultat de la consanguinité en 4 secondes au lieu de 3 minutes.

Avec le fichier de 13.000 individus, c'est pas la même chose... Calcul de sosas assez rapide, environ 5 secondes, par contre pour la consanguinité limités aux sosas, ça tourne depuis plus de 90 minutes, UC à 100% et je vais tuer la bête pour aller me coucher !   ... Je réinstallerai la sauvegarde tout à l'heure car je pense que ça va planter au redémarrage de Ancestrologie...



Cordialement



Joël

[Joël AUGUSTE]

Bonjour,



Ce matin j'ai redémarré Ancestrologie après avoir "tué" le calul de consanguinité et contrairement à la dernière fois, je n'ai pas eu de message d'erreur : "internal gds software consistency check (can't continue after bugcheck)". La basse était passé de 37.000 Ko à 55.000 Ko et j'ai même pu faire une optimisation.

J'ignore toutefois si la base n'est quand même pas corrompue et je vais remettre la sauvegarde à la place afin de ne pas prendre le risque de me retrouver avec une base inaccessible dans quelques temps.



Cordialement



Joël

[DDdeBerdeux]

Quelques essais sur la base de Joël m'a fait, je pense, trouver la raison des blocages.

J'ai fait la requête suivante:

Code: [Sélectionner]

select * from individu

where cle_fiche=cle_pere

         or cle_fiche=cle_mereL'individu NIP 10041 (Christopher RHUYS-JONES) a pour fils "lui-même".

Et je pense qu'il doit y avoir d'autres références circulaires comme celle-ci, avec plusieurs générations d'écart.

Reste à trouver une requête capable de détecter ces anomalies...

L'importation du gedcom dans KStableau détecte un grand nombre d'anomalies de dates (ex: enfant à -32 ans).

A+

André

[Pierrot]

Effectivement quand je passe mon GED par KStableau j'ai un enfant à moins 7 ans et un autre à moins 2

[Joël AUGUSTE]

Bonjour,



Effectivement j'ai retrouvé cette erreur.

De plus, il avait également lui-même comme père et sa propre épouse comme mère.

Je ne pense pas qu'il puisse s'agir d'une erreur de saisie, je conçois que lorsque des individus ont le même patronyme et le même prénom, on puisse se tromper, mais 3 erreurs sur la même fiche dont celle de mettre sa propre épouse comme sa propre mère, ça fait peut-être un peu gros.

J'ai remis en place la base qui n'a pas été polluée par un cacul avorté de consanguinité et bien sûr l'erreur décélée par André s'y trouvait également.

Quant aux erreurs de dates, je l'avais déjà détecté avec KStableau dans l'autre dossier, celui de 2.300 individus (je n'avais pas testé le dossier de 13.100 individus avec KStableau). J'avais vérifié quelques erreurs, et à chaque fois, il n'y avait pas d'erreur dans Ancestrologie, cela provenait d'une date telle que "avant 1840" par exemple. Il y avait également de nombreuses erreurs dans les unions (mariages pas dans l'ordre ?), je n'avais également pas détecté d'erreur dans Ancestrologie, mais ce qui est fort probable, c'est que les unions n'avaient pas été saisies dans l'ordre chronologique, mais les dates des unions sont bonnes et Ancestrologie les reclasse bien dans l'ordre sur la fiche.

Je vais étudier l'aide de KStableau, reprendre les erreurs une par une et je vous tiendrai informé.

Encore merci à André.



Cordialement



Joël

[DDdeBerdeux]

Bonjour,

Je pensais qu'Ancestrologie détectait ces erreurs lors de la saisie, mais il peut y avoir plusieurs causes:

controle supprimé par l'utilisateur,

import d'un gedcom?

individus sans dates, ancestro faisant les contrôles d'après les dates de naissance ou décès (à vérifier)?

J'ai parlé de KStableau parce que je pense que les erreurs de bouclage "individu-ancêtre" devraient être détectées comme des erreurs de dates. Mais il est fort possible que si les dates ne sont pas mentionnées, l'erreur ne soit pas détectée.

Ces erreurs devraient également provoquer des blocages lors de l'affichage des arbres ou états d'ascendance, encore faudrait-il trouver les bons individus. J'ai essayé de faire une requête utilisant une procédure "arbre" qui s'est évidemment bloquée.

Il faudrait faire une procédure qui pour chaque individu analyse chaque niveau de son ascendance avant de passer au suivant, sinon elle bloque. C'est pas tout simple. Peut-être serait-il utile de l'inclure dans la base pour pouvoir débloquer des situations comme la votre?

A+

André

[Joël AUGUSTE]

Bonjour,



Je viens de refaire la vérification d'un dossier de ma base (2.300 individus) avec KStableau.

Cela m'a permis de découvrir 2 erreurs de frappe dans les dates, mais également qu'il n'y avait pas d'alarme d'Ancestrologie par exemple pour un individu qui a un décès en 1840 et un mariage en 1850.

En ce qui concerne les "mariages pas dans l'ordre ?" détectés par KStableau, il s'agit vraisemblablement du tri dors de l'export gedcom généré Ancestrologie (je ne suis pas spécialiste) car ils sont bien dans l'ordre sur la fiche, mais la saisie n'a sûrement pas été faite dans l'ordre chronologique des mariages. Voir également ici : http://www.ancestrologie.org/forum/index.php?topic=5184.0&postdays=0&postorder=asc&start=15



J'ose à peine m'attaquer au dossier de 13.100 individus... Je vais sûrement avoir des pages et des pages d'erreurs réelles ou provenant de l'export gedcom ?...



Cordialement



Joël

[Joël AUGUSTE]

Bonjour,



J'ai vérifié le dossier de 13.100 individu avec KStableau, le nombre d'erreurs est moins important que prévu.

Un nouveau type d'erreurs est apparu pour les personnes ayant plusieurs unions. On trouve des remariages avant séparation alors que dans Ancestrologie les dates sont correctes. Il s'agit peut-être de l'ordre dans lequel les unions ont été saisies.

Par contre, lorsque je veux construire un arbre, j'ai un message d'erreur indiquant : il semble qu'il y ait une boucle dans votre gedcom.

L'erreur décélée par André avait été corrigée avant de faire l'export gedcom. Il s'agit donc d'une autre erreur.



Cordialement



Joël

[DDdeBerdeux]

Bonjour,

Je pense qu'il doit y avoir d'autre bouclages du même type, mais avec plusieurs générations d'écart.

Exemple;

fils: Alain

père: Jean

GP: Paul

AGP: Alain

Mais pas facile de les trouver

J'ai essayé de faire une procédure PROC_REF_CIRC(dossier) pour détecter les références circulaires dans un dossier, mais elle se plante elle même et je ne vois pas où est le bouclage. Comme je n'en ai pas trop le temps en ce moment, si un "courageux", peut trouver la raison, je lui met ci-dessous le script qui permet de la créer.

Code: [Sélectionner]

COMMIT WORK;

SET AUTODDL OFF;

SET TERM ^ ;



/* Stored procedures */



CREATE PROCEDURE "PROC_REF_CIRC"

(

  "I_DOSSIER" INTEGER

)

RETURNS

(

  "CLE_FICHE" INTEGER,

  "NOM" VARCHAR(40) CHARACTER SET ISO8859_1,

  "PRENOM" VARCHAR(60) CHARACTER SET ISO8859_1,

  "CLE_ENFANT" INTEGER,

  "NOM_ENFANT" VARCHAR(40) CHARACTER SET ISO8859_1,

  "PRENOM_ENFANT" VARCHAR(60) CHARACTER SET ISO8859_1

)

AS

BEGIN EXIT; END ^





ALTER PROCEDURE "PROC_REF_CIRC"

(

  "I_DOSSIER" INTEGER

)

RETURNS

(

  "CLE_FICHE" INTEGER,

  "NOM" VARCHAR(40) CHARACTER SET ISO8859_1,

  "PRENOM" VARCHAR(60) CHARACTER SET ISO8859_1,

  "CLE_ENFANT" INTEGER,

  "NOM_ENFANT" VARCHAR(40) CHARACTER SET ISO8859_1,

  "PRENOM_ENFANT" VARCHAR(60) CHARACTER SET ISO8859_1

)

AS

/* création par André le 9/01/2006 pour retrouver les références circulaires*/

declare variable i integer;

declare variable i_count integer;

declare variable I_CLEF integer;

begin

  for select cle_fiche,nom,prenom

      from individu

      where kle_dossier=:i_dossier

      order by cle_fiche

      into :cle_fiche,:nom,:prenom

    do

    BEGIN

      delete from TQ_ARBREREDUIT;

      insert into TQ_ARBREREDUIT (TQ_DOSSIER,tq_niveau,tq_cle_fiche)

             values(:I_DOSSIER,0,:cle_fiche);

      i=0;

      i_count=1;

      while (i_count>0) do

        begin

          FOR SELECT tq_cle_fiche FROM tq_arbrereduit

           WHERE tq_niveau =:i

           INTO :I_CLEF

           DO

           BEGIN

            insert into TQ_ARBREREDUIT (TQ_DOSSIER,tq_niveau,tq_cle_fiche)

              select :I_DOSSIER,:i+1,cle_pere

                  from individu

                  WHERE cle_fiche = :I_CLEF AND CLE_PERE IS NOT NULL;

            insert into TQ_ARBREREDUIT (TQ_DOSSIER,tq_niveau,tq_cle_fiche)

              select :I_DOSSIER,:i+1,cle_mere

                  from individu i

                  WHERE i.cle_fiche = :I_CLEF AND CLE_MERE IS NOT NULL;

            for select :i_clef,i.nom,i.prenom

                from tq_arbrereduit t,individu i

                where t.TQ_NIVEAU=:i+1 AND

                      t.tq_cle_fiche=:cle_fiche AND

                      i.CLE_FICHE=:i_clef

                into :cle_enfant,:nom_enfant,:prenom_enfant

                do

                begin

                  suspend;

                  i_count=0;

                end

           END

           If (i_count>0) then

             BEGIN

               i = i + 1;

               Select Count(0) from tq_arbrereduit where tq_niveau=:i into :i_Count;

               if (i >100) then I_COUNT = 0;

             END

        end

    END

end

 ^



SET TERM ; ^

COMMIT WORK;

SET AUTODDL ON;A+

André

[Joël AUGUSTE]

Bonjour,



Autre piste de recherche : quelqu'un connaitrait-il un logiciel qui analyse les gedcom, qui détecte en particulier les erreurs de boucle et surtout qui indique sur quel individu se trouve cette erreur ?

J'ai déjà cherché sur le net et je n'ai rien trouvé.

Malheureusement, je n'y connais rien en programmation informatique et je ne peux être d'aucune aide dans la procédure amorcée par André...  



Cordialement



Joël

[garnierfrancoise]

Certains disent (et je suis disposé à les croire) que KS Tableau est un des meilleurs analyseurs de Gedcom; mais traite-t'il le cas posé? A Philippe le Pro de KST