forum Ancestrologie
Ancestrologie - Le Programme => Ancestrologie - Rapports d'anomalies => Discussion démarrée par: Joël AUGUSTE le 06 Janvier 2006 à 20:58:41
-
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
-
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 travailleJe 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é.
-
Je pensais que lorsque le gestionnaire de tâches indiquait : "pas de réponse", cela signifiait que le programme était bloqué ! :oops:
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
-
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é
-
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
-
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é
-
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
-
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
-
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é
-
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... :lol:
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 ! :evil: ... Je réinstallerai la sauvegarde tout à l'heure car je pense que ça va planter au redémarrage de Ancestrologie...
Cordialement
Joël
-
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
-
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: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é
-
Effectivement quand je passe mon GED par KStableau j'ai un enfant à moins 7 ans et un autre à moins 2
-
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
-
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é
-
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
-
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
-
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.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é
-
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
-
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
-
J'ai essayé KStableau, voir messages plus haut.
C'est lui qui me dit que j'ai une boucle dans mon gedcom, mais il ne dit pas sur quel individu ! ... Et j'en ai 13.100 !
-
J'ai essayé KStableau, voir messages plus haut.
C'est lui qui me dit que j'ai une boucle dans mon gedcom, mais il ne dit pas sur quel individu ! ... Et j'en ai 13.100 !
Il faut peut-être vérifier ma traduction en refaisant un contrôle dans la version anglaise.
S'il y a bien une boucle, je poserai la question au concepteur. çà demandera un peu de temps, je ne manipule l'anglais qu'à faible dose même si je me débrouille pour le lire (et l'interprêtrer).
-
Il faut peut-être vérifier ma traduction en refaisant un contrôle dans la version anglaise.
S'il y a bien une boucle, je poserai la question au concepteur. çà demandera un peu de temps, je ne manipule l'anglais qu'à faible dose même si je me débrouille pour le lire (et l'interprêtrer).
Heu... Je maîtrise aussi bien l'anglais que la programmation informatique... :lol:
Si tu veux, je peux t'envoyer le gedcom dans ta bal perso et tu pourras vérifier ta traduction ?
Cordialement
Joël
-
Si tu veux, je peux t'envoyer le gedcom dans ta bal perso et tu pourras vérifier ta traduction ?
Beaucoup trop gros pour moi ... pour le moment.
Conserve une copie de cette base, un... certain temps, en attendant que j'ai une réponse.
Le message en anglais est "There seems to be a loop in your gedcom." sans plus de précision.
-
la traduction est bonne (au moins litteralement :!: ), je confirme. maintenant n'utilisant pas ks tableau que cela signifie-t-il concretement :?: que le gedcom comprend des implexes :?:
-
Ce que j'ai pu décrypter de tout un charabia parfois contradictoire que l'on trouve sur internet concernant la définition de "implexe".
En principe c'est un rapport entre le nombre d'ancêtres réels que l'on retrouve jusqu'à une génération et le nombre d'ancêtres théorique jusqu'à cette même génération. On retrouve souvent le complément à 1 de ce rapport, c'est à dire (anc théoriques-anc trouvés)/anc théoriques et c'est cette définition qui est utilisée dans l'état de dénombrement d'ascendance d'ancestrologie. Il est représentatif d'une perte d'ancêtres due aux ancêtres que l'on retrouve plusieurs fois dans sa généalogie ascendante.
Par extension on utilise souvent le même nom "implexes" pour ces individus que l'on retrouve plus d'une fois dans sa généalogie ascendante, par des branches différentes.
Où çà se complique encore, c'est quand on utilise le même mot pour désigner le rapport et les individus que l'on retrouve plusieures fois dans une généalogie descendante. On peut en effet retrouver des enfants dont le père et la mère sont tous 2 des descendants de l'individu d'origine. C'est pour celà que j'avais posé la question de l'appellation dans un fil sur le forum Echanges libres http://www.ancestrologie.org/forum/index.php?topic=5270.0 sans beaucoup de réponses :cry:
Maintenant quand on parle de boucles (je n'avais pas vu que KStableau détectait leur présence), il s'agit de tout autre chose. C'est quand un individu est cité dans sa descendance ou ascendance, ce qui n'est qu'une erreur de saisie. Ancestro doit le signaler quand il les détecte par les dates de naissance, mais quand il n'y a pas de date? C'est pour celà qu'il serait intéressant de faire une procédure qui les détecte formellement...
A+
André
-
Bonjour,
Pour compléter ce qu'a écrit André au sujet des détections par Ancestrologie, je viens de faire un test dans un dossier vierge :
J'ai créé une fiche Dupont Jean, marié à Duchemin Jeanne, j'ai ajouté un enfant commun qui a le même prénom que le père. Je n'ai mis aucune date.
Ensuite, j'ai ajouté un père à la 1ère fiche créée (Dupont Jean), la fenêtre s'ouvre automatiquement sur Dupont et j'ai volontairement cliqué sur le prénom du fils. Ancestrologie l'a accepté sans aucun problème. On se retrouve donc avec une personne qui a pour père son propre fils, c'est bien le type de boucle décelée par André dans un message ci-dessus
Par contre, on en peut pas ajouter soi-même comme père car on a le message suivant : "L'individu ne peux pas être à la fois, lui même et son père" (avec en passant un faute d'orthographe à peux).
Je pense que dans le cas de mon 1er exemple, valider son fils comme son propre père, Ancestrologie devrait également lancer un message d'alerte.
Cordialement,
Joël
-
On se retrouve donc avec une personne qui a pour père son propre fils, c'est bien le type de boucle décelée par André dans un message ci-dessus
Et que dit le contrôle de KStableau dans ce cas ?
J'aimerai savoir car j'ai plusieurs messages de détection de boucle, et certain qui précisent l'individu ou la famille.
-
Et que dit le contrôle de KStableau dans ce cas ?
J'aimerai savoir car j'ai plusieurs messages de détection de boucle, et certain qui précisent l'individu ou la famille.
Je viens donc de faire l'essai avec un gedcom de 3 individus différents (mais 4 virtuels car l'un est à la fois le fils et le père d'un autre).
KStableau répond avec le message suivant dans le cadre en bas à droite lorsqu'on veut faire un arbre de descendance :
3 noms dans l'arbre.
*** Il semble qu'il y ait une boucle dans votre gedcom.
*** obsolete ***
*** Une erreur a été rencontrée.
C'est exactement la réponse d'erreur que j'ai eu avec le gedcom de 13.100 individus.
Cordialement
Joël
-
Le message "obsolète" m'avait été donné comme n'étant pas à traduire.
Je le traduis ici :
KStableau ne peut pas indiquer exactement la cause du problème.
Essayez la fonction implexe (inbreeding) . Il y a une chance que vous obteniez plus
d'informations sur le problème par cet intermédiaire.
Ceci ne donne pas une réponse, mais oriente la recherche. Et comme KStableau détecte très bien les implexes, çà peut servir.
Tient moi au courant sur la réponse aux implexes dans ta grosse base.
-
As-tu fait l'essai avec un écart de générations plus important dans ta boucle?
KStableau possède des fonctions très intéressantes (je m'aperçois que j'ai fait presque la même chose dans la b4.012 en test, sans le savoir sur le calcul de parenté en b4.010 et la procédure de recherche d'ancêtres communs = implexes).
Mais pour la recherche des boucles, ce n'est fait que par ascendance ou descendance, et c'est un coup de chance de tomber sur "l'individu" qui a justement une boucle. S'il faut faire l'ascendance de chaque individu un par un ...
A+
André
-
Ceci ne donne pas une réponse, mais oriente la recherche. Et comme KStableau détecte très bien les implexes, çà peut servir.
Tient moi au courant sur la réponse aux implexes dans ta grosse base.
Je viens de faire l'essai avec KStableau sur les implexes avec le gedcom de 3 individus, voici la réponse obtenu dans le cadre en bas à droite :
*** Il y a une boucle infinie dans vos données.
*** Ceci signifie que l'enfant de quelqu'un est également son ascendant.
La trace suivante devrait vous permettre de localiser le problème : chaque ligne correspond à un enfant de la personne de la ligne au-dessus.
(I25815) André Dupont
(I25812) André Dupont
(I25815) André Dupont
La dernière personne se trouve déjà dans cette liste, et apparait donc comme un ancêtre d'elle-même
*** Une erreur a été rencontrée.
J'ai ensuite fait l'essai avec le gedcom de 13.100 individus, le type de réponse n'est pas le même, on a un pavé qui s'affiche à l'écran :
Il y a certainement une boucle dans votre gedcom.
Le problème est détectée en cherchant la parents de (I10014) Alexandra Saxe-cobourg-gotha (de). (transcription au mot à mot)
On clique sur OK et on a un message disant qu'il faut faire Echap (Esc) pour interrompre le calcul.
J'ai fait la recherche avec Ancestrologie et je n'ai pas trouvé de boucle sur cette fiche. De plus, les parents, le conjoint et les enfants ont tous des dates précises de naissance et de décès ainsi que des prénoms différents, c'est donc plus facile à vérifier !...
Cordialement
Joël
-
As-tu fait l'essai avec un écart de générations plus important dans ta boucle?
Je viens de faire l'essai avec KStableau en ayant créé une boucle sur le grand-père, j'obtiens le même message d'erreur à la construction d'un arbre descendant :
4 noms dans l'arbre.
*** Il semble qu'il y ait une boucle dans votre gedcom.
*** obsolete ***
*** Une erreur a été rencontrée.
Par contre, quand on fait un calcul d'implexe, aucune erreur n'est détectée, on obtient juste la réponse suivante :
Echap (Esc) pour interrompre le calcul
Aucun implexe détecté dans ce fichier.
Pas de fichier à voir
Cordialement
Joël
-
J'ai fait la recherche avec Ancestrologie et je n'ai pas trouvé de boucle sur cette fiche.
L'erreur se produit bien lors de la détection d'un implexe, mais la boucle n'est pas forcément sur cette fiche, mais sur les parents au sens large, c'est à dire sur un ascendant.
-
L'erreur se produit bien lors de la détection d'un implexe, mais la boucle n'est pas forcément sur cette fiche, mais sur les parents au sens large, c'est à dire sur un ascendant.
Je viens de faire l'ascendance de l'individu désigné (Alexandra de Saxe...) avec KStableau, aucun problème, j'ai l'ascendance complète.
Avec Ancestrologie, j'ai demandé dans impressions documents, l'ascendance complète. J'ai remarqué que à partir de la 27ème génération certains noms ne s'affichaient pas en face du n° Sosa, par contre, si il y a des dates, celles-ci s'affichent. J'ai demandé l'impression dans un fichier word et il y a le même problème d'affichage du nom avec les mêmes numéros de sosa. Plus on augmente dans le nombre de générations, plus il y a de noms manquants. J'ai pu retrouver certains noms grace aux dates de naissance et de décès.
Par contre, le nom s'affiche normalement dans l'arbre d'Ancestrologie : je parle de l'arbre qui se trouve sous impressions dans la colonne de gauche.
Affichage normal également dans l'arbre de KStableau en ce qui concerne les noms qui ne s'affichent pas dans Ancestrologie.
Cordialement
Joël
-
Il doit bien y avoir bouclage sur cet individu car un calcul de consanguinité suivant la renumérotation sosa plante. Par contre un calcul de consanguinité sur lui seul PROC_PARENTE(10014,0) se déroule normalement. Mais cette procédure ne scrute pas plus loin que la 9ième ou 10ième génération (influence sur la consanguinité négligeable au delà). C'est donc que le bouclage doit être après la gen 9?
J'ai essayé avec la b4.012 qui est en test.
La PROC_ANC_COMMUNS(10014,0) qui doit faire ressortir les implexes plante également car elle lit toute l'ascendance avant de chercher les implexes.
Les états d'ascendance et de descendance complets font apparaître les implexes. Ils se déroulent normalement. C'est normal parce que dans la méthode utilisée, si un individu a déjà été trouvé une fois, son ascendance n'est plus recherchée. Mais par contre il doit se trouver dans les implexes trouvés. Si çà peut vous aider à les trouver...
Autre chose qui m'a étonnée, c'est que vous avez de nombreuses fiches sans nom, identifiées uniquement par le NIP. Dans ces conditions il n'est pas étonnant de faire des erreurs d'identification lors de la saisie :roll:
A+
André
PS: me serais-je trompé sur ces individus sans noms? Cà ne serait pas une erreur qui arrive pour des SOSA >2^30, auquel cas, il va falloir regarder çà avec PCM, dans le pipeline qui cumule le nom avec le NIP
-
Et non... Je pense avoir trouvé la raison de la disparition du nom, elle est dans la procédure stockée. Je vais pouvoir inclure la correction en b4.012.
Les individus en question n'ont pas de prénom, et la concaténation de NOM||NULL renvoie NULL!
A+
André
-
Autre chose qui m'a étonnée, c'est que vous avez de nombreuses fiches sans nom, identifiées uniquement par le NIP. Dans ces conditions il n'est pas étonnant de faire des erreurs d'identification lors de la saisie :roll:
André,
Je n'ai pas de noms manquants dans la base, mais il est vrai pas mal de prénoms absents, c'est le cas par notament pour les rois : Henri II, Henri III, mais lorsqu'un roi a un surnom par exemple Henri IV le Grand, "Henri IV" est le nom et "le Grand" le prénom.
Dans les vérifications de noms absents de "impressions / documents / ascendance complet" ceux que j'ai trouvés relevaient bien de l'exemple ci-dessus, mais je n'ai vérifié que quelques fiches. Et dans l'arbre, le nom était bien indiqué ! Mais la procédure de recherche n'est peut-être pas la même selon qu'il s'agit d'un document ou d'un arbre ?
Cordialement
Joël
-
C'est réparé, mais dans la d4.012. J'ai bien vérifié, maintenant le nom apparaît bien.
Effectivement, les procédures états utilisent les procédures arbres ou descendances, mais en concaténant le nom et le prénom et c'était là ce problème, si l'un est NULL, tout est NULL. Mais tout celà est indépendant de ton problème de bouclage. As-tu vérifié avec la b4.012 qui te donne les implexes?
A+
André
-
As-tu vérifié avec la b4.012 qui te donne les implexes?
Bonjour,
Je viens de passer en b4.012 (je suis resté en v420).
En repartant de Alexandra de Saxe-Cobourg-Gotha l'affichage des noms est maintenant complet. Je n'ai trouvé aucun implexe de noté.
J'ai choisi Alexandra comme sosa, toujours aucun implexe. J'ai refait un calcul de consanguinité limité aux sosas sur la même personne, mais toujours le blocage. J'ai donc "tué" la calcul.
Une solution pour trouver où se situe la boucle (ou une des boucles :cry: ), c'est peut-être de faire, depuis Anecstrologie, une extraction gedcom limitée aux ascendants de Alexandra et de la tester avec KStableau, je vais faire ça cet après-midi.
Cordialement
Joël
-
En repartant de Alexandra de Saxe-Cobourg-Gotha l'affichage des noms est maintenant complet. Je n'ai trouvé aucun implexe de noté.
Bonjour,
Si tu veux voir les implexes dans l'état d'ascendance complet, il faut passer à la v433.
Tu verrais que les sosas 16 et 17 figurent également comme sosas 22 et 23.
Implexes sous forme de tableau:
SOSA IMPLEXE
22 16
23 17
62 56
63 57
106 56
107 57
108 42
208 206
209 207
210 66
211 67
396 384
397 385
414 160
415 161
480 398
481 399
etc, j'arrête en page 6, mais il y a 45 pages d'ascendance, et 223 implexes...
Une requête qui les liste:select * from PROC_ETAT_ASCENDANCE(10014,0,3,0)
WHERE IMPLEXE IS NOT NULLJ'aurai dû commencer par là au lieu d'essayer de les lister sur l'état. D'autant plus que cette requête ne nécessite pas la v433, juste la base b4.012.
A+
André
-
re bonjour,
La vérification des ascendants de Alexandra avec KStableau ne m'a pas permis de détecter où il y avait une boucle, mais d'autres erreurs sont apparues listées par KStableau :
1) Deux enregistrements FAM sont identiques. (soit la personne s'est mariée deux fois, alors que ces mariages ne peuvent être distingués soit on ne peut déterminer quel mariage est le premier) Il y en a plusieurs dizaines. J'ai vérifié les 3 premières anomalies. Sur la 1ère, il y a 2 mariages avec dates, mais les enfants ne sont affectés qu'au père (volontaire ou involontaire, je n'ai pas encore vérifié). Sur la 2ème, 1 seule union datée, l'enfant n'est affecté qu'au père (volontaire ou involontaire ?) Et sur la 3ème, 2 mariages datés, 7 enfants dont 5 pour une épouse, 1 pour l'autre et le 7ème affecté uniquement au père.
2) Le lien CHILdans l'enregistrement FAM n'existe pas (la famille contient un enfant pour lequel il n'y a pas d'enregistrement INDI. Il y en a des dizaines et des dizaines. J'ai vérifié les 3 premières anomalies. Sur la 1ère, 2 unions datées alors que SKtableau indique WIFE inconnu(e), 7 enfants dont 4 pour une épouse et 3 pour l'autre. J'ai remarqué que bien qu'il y ait 7 enfants, il était indiqué dans Ancestro 4 enfants connus. Dans les préférences / options de saisie, j'ai bien décoché la case remplissage automatique du NCHI et NMR à chaque fiche, mais j'avais commencé ce dossier avec cette case cochée. Sur la 2ème, 1 union datée, 6 enfants bien affectées aux 2 conjoints mais KStableau n'en prend qu'un seul, celui qui a le numéro sosa. Pour la 3ème, (il s'agit de Alexandra de Saxe...) date du mariage indiquée dans KS, mais époux inconnu et enfants inconnus alors que dans Ancestro, ils sont tous normalement affectés.
3) Le lien HUSB de l'enregistrement FAM n'existe pas. (la famille annonce un mari pour lequel in n'y a pas d'enregistrement INDI.). Vérification de 3 fiches, la 1ère 2 unions, mais un seul mariage. Sur la 2ème, 2 unions, déclarés mariés, datées dont une avec date "avant 1204". pour la 3ème, 2 unions, déclarés mariés et datées. Il n'y a que quelques erreurs de ce type, on trouve aussi le même genre avec "...annonce une épouse pour laquelle..."
Avec mes excuses pour avoir été aussi long...
Dernière remarque, l'extraction gedcom avait été faite depuis la base avec laquelle j'avais "tué" le calcul de consanguinité. Je vais refaire une extraction avec la sauvegarde que j'espère propre et je comparerai.
Cordialement
Joël
-
Dernière remarque, l'extraction gedcom avait été faite depuis la base avec laquelle j'avais "tué" le calcul de consanguinité. Je vais refaire une extraction avec la sauvegarde que j'espère propre et je comparerai.
Exportation gedcom faite avec une base (a poriori) saine de corruption suite à une interruption volontaire du calcul de consanguinité, on obtient avec KStableau les mêmes résultats en nombre, c'est à dire :
Liens FAMS incorrects (61x)
Liens CHIL incorrects (1066x)
Liens HUSB/WIFE incorrects (216x)
Cela fait quand même beaucoup car l'export gedcom contient 1002 personnes pour 858 familles. Il est vrai que pour les enfants incorrects, l'erreur est répétée pour chaque enfant déclaré manquant du couple ou du père.
Cordialement
Joël
-
Cela fait quand même beaucoup
Un certain nombre de ces erreurs sont "normales" et il ne faut pas en tenir comte, car l'extrait fait par Ancestro crée des ruptures de liens, les conjoints n'étant (sauf erreur de ma part) pas récupérés ou pas toujours.
Je pense qu'il faut concentrer ton analyse sur la recherche de l'anomalie initiale, la boucle
Si tu utilises Visuged pour faire un extrait, tu auras surement des messages moins nombreux
-
Je pense qu'il faut concentrer ton analyse sur la recherche de l'anomalie initiale, la boucle
Si tu utilises Visuged pour faire un extrait, tu auras surement des messages moins nombreux
C'est bien ce que je compte faire... En commençant par les implexes dont parle André.
Je vais utiliser également Visuged, mais l'inconvénient de ce logiciel c'est que, contrairement à KStableau, il n'indique pas le nom de l'individu où il y a une erreur, mais seulement son numéro, la recherche va donc être beaucoup plus longue... 95% des erreurs de Visuged sont : l'enfant n°xxxxx n'a pas été décrit précédemment à cette union n°xxxxx (err.123) et 5% sont : l'époux n°xxxxx n'a pas été décrit précédemment à cette union n°xxxxx. il n'est pas pris en compte (err.121).
Joël
-
Bonjour,
J'ai commencé la recherche des boucles possibles sur les 223 individus qui ont des implexes en sortant un tableau grace à la formule SQL de André.
J'ai commencé par les noms qui figuraient en double dans la liste, je n'ai pas fini, mais je pense que je n'en trouverai sûrement pas car j'ai regardé en priorité ceux qui n'avaient pas de date.
Par contre j'ai découvert un problème en ce qui concerne le calcul des Sosas, voici 2 exemples :
ANGLETERRE (D’) Georges Ier (il n'y en qu'un seul) CLE_FICHE = 4690 :
- N° Sosa sur fiche de saisie Ancestrologie = 160
- N° Sosa dans impressions / documents / ascendance complet = 414 + 160
- N° Sosa dans requête SQL = 414 (un seul Sosa)
BARCELONE (DE) Bérengère (il n'y en a qu'une seule) CLE_FICHE = 9052 :
- N° Sosa sur fiche de saisie Ancestrologie = 42162193
- N° Sosa dans impressions / documents / ascendance complet = 42152977 (un seul Sosa)
- N° Sosa dans requête SQL = 42168359 + 84306023
Si pour le 1er exemple, il y a des convergences dans les numéros, il n'y en a aucun dans le 2ème exemple ! :(
J'ai vérifié les CLE_FICHE ou clé lien interne, ce sont bien les mêmes dans le tableau SQL et sur la fiche Ancestrologie
Cordialement
Joël
-
Bonjour,
J'ai fait comme vous avec v433 et b4.012. J'ai commencé par faire dans ancestro la renumérotation sosa à partir d'Alexandra 10014.
J'ai édité l'état d'ascendance d'Alexandra dans Ancestro et fait la requête suivanteselect p.cle_fiche,p.generattion,p.sosa,p.implexe,i.num_sosa,p.nom
from PROC_ETAT_ASCENDANCE(10014,0,3,0) p, individu i
WHERE IMPLEXE IS NOT NULL and i.cle_fiche=p.cle_fiche
order by p.cle_fiche, p.generattion,p.sosalégèrement modifiée pour faire apparaître uniquement les champs intéressants et le NUM_SOSA issu de la fiche.
Premier résultat: l'état et la requête (sauf limitation aux implexes) donnent le même résultat, ce qui est normal puisqu'ils utilisent la même procédure.
La requête (et l'état) appellent SOSA le n° attribué en suivant les branches ascendantes, et mettent dans IMPLEXE le premier n° SOSA attribué au même individu.
La procédure de renumérotation SOSA utilisée par Ancestrologie, utilise la même logique, sauf qu'elle se limite à la première fois que l'individu est trouvé sur une branche, et ne le "ressort" plus ensuite même s'il est trouvé sur une autre branche.
Vous comprenez donc que si dans les 2 procédures, les branches ascendantes ne sont pas explorées exactement dans le même ordre, la "première fois" ne sera pas obligatoirement la même donc le SOSA sera différent.
Mais la méthode sortant les implexes, calculant tous les SOSA d'un individu, il devrait y en avoir au moins un égal au NUM_SOSA de la fiche.
Pour 4690 la requête donne sosa 414 et implexe 160, comme le NUM_SOSA de la fiche donc tout est normal.
Pour 9052 la requête ressort 2 lignes
génération 26 sosa 42168329 implexe 42152977 NUM_SOSA 42162193
génération 27 sosa 84306023 implexe et num_sosa comme au dessus.
Aucun des 3 n° trouvés dans la requête n'est celui de la fiche, il y a donc une anomalie qu'il faudrait rechercher dans les générations d'avant.
A+
André
-
Aucun des 3 n° trouvés dans la requête n'est celui de la fiche, il y a donc une anomalie qu'il faudrait rechercher dans les générations d'avant.
Quand tu dis qu'il faudrait chercher l'erreur dans les générations d'avant, cela signifie bien que l'anomalie se tiendrait dans les individus de l'ascendance situés entre Alexandra 10014 et Bérengère 9052 ?
Si c'est bien ça que j'ai compris, ça va limiter le champ des recherches ! ... Pour cette anomalie ... :wink:
Joël
-
Oui, mais ce n'est pas facile pour autant, car il y a 26 générations d'écart...
Et redescendre les générations en divisant les sosa par 2, poufffff. :?
Je préfère regarder la PROC_REF_CIRC, elle serait plus utile pour tout le monde.
A+
André
-
Dernière expérience du jour.
J'ai pris la base de PCM de 147 individus.
Le dernier (pour le moment) de la lignée: Kévin né en 1997.
J'ai remonté les générations jusqu'à la 8ième, Paul né en 1780 qui n'avait pas de père connu.
Je lui donne Kévin comme père. Ancestro l'accepte sans aucune alerte.
Je vais sur la fiche de Kévin; une fenêtre bleue signale que Kévin était trop jeune pour être père (normal à -217 ans :wink: ).
Le supprime l'évènement naissance de Kévin. Depuis plus de fenêtre signalant l'incohérence.
Cà m'a permis d'essayer la PROC_REF_CIRC. Elle fonctionne correctement, mais il faut plus d'une seconde pour analyser une base de 147 individus, et sort les 8 individus qui se trouvent sur la boucle. Logique.
Je vais la réessayer sur votre base, mais je la lancerai avant d'aller me coucher...
A+
André
-
Cà m'a permis d'essayer la PROC_REF_CIRC. Elle fonctionne correctement, mais il faut plus d'une seconde pour analyser une base de 147 individus, et sort les 8 individus qui se trouvent sur la boucle. Logique.
Je vais la réessayer sur votre base, mais je la lancerai avant d'aller me coucher...
Merci André, mais je me pose la question si au vu du nombre important des implexes, des boucles "normales" ne peuvent-elles pas exister ? (mariages entre cousins, avec des oncles ou tantes, etc...)
Pour faciliter la recherche, j'ai fait un export gedcom des ascendants d'Alexandra sur 29 générations pour le réintégrer dans une autre base sur Ancestrologie. A Bérengère, je m'aperçois qu'il lui manque un enfant. Mais l'enfant qui lui manque n'est pas un sosa de Alexandra, c'est pour ça qu'il n'a pas été pris dans l'export.
Quand on voit le nombre d'enfants par couple qui sont des sosas alors qu'en ligne directe, un seul devrait l'être...
Bonne fin de soirée, je vais arrêter mes recherches pour l'instant, je commence à avoir les yeux qui se croisent...
A+
Joël
-
Quand on voit le nombre d'enfants par couple qui sont des sosas alors qu'en ligne directe, un seul devrait l'être...
C'est pour celà que le couple fait partie des implexes. C'est même comme çà que je détecte les implexes. Les branches venant de ind1 et de ind2, arrivent à l'implexe par un enfant différent. Si c'était par le même enfant, l'implexe serait cet enfant.
Bonne nuit.
André
-
Bonjour,
Recherches de références circulaires arrêtées au bout de 8 heures.
Par contre, est-il normal qu'une mère ait un enfant avec son fils!
C'est le cas de GONNOR 11323 qui avec son fils Richard II de Normandie 11324, a eu pour fils Rober 1er de Normandie 6517, un des ancêtres d'Alexandra.
Après vérification, ce n'est pas çà qui provoque le bouclage dans le calcul de consanguinité. J'ai tout de même fait un calcul de consanguinité en supprimant la récursivité de la formule, et le calcul aboutit...
A+
André
-
Bonjour
C'est le cas de GONNOR 11323 qui avec son fils Richard II de Normandie 11324, a eu pour fils Rober 1er de Normandie 6517, un des ancêtres d'Alexandra.
Après vérification, ce n'est pas çà qui provoque le bouclage dans le calcul de consanguinité. J'ai tout de même fait un calcul de consanguinité en supprimant la récursivité de la formule, et le calcul aboutit...
Il s'agit bien d'une erreur, mais il y a eu plusieurs Richard de Normandie nés et décédés dans les mêmes périodes. Je reprendrai la généalogie exacte plus tard.
J'ai également supprimé cette boucle mais je n'ai pas pu aboutir au calcul de consanguinité limité aux ascendants d'Alexandra. J'ai tué le calcul au bout de 15 minutes.
Une question, lorsqu'on tue un calcul de consanguinité, et que l'on peut rouvrir Ancestrologie aves cette base dont la taille peut avoir été multipliée par 10, reste-t-il dans la base des traces de ce calcul qui pourrait venir polluer un prochain calcul, même après une optimalisation ?
A+
Joël
-
Non, car si tu tues la tâche FB, les modifications dans la table temporaire ne sont pas validées, mais tu as de la chance de pouvoir l'optimiser. Chez moi il est fréquent que la base soit corrompue au point qu'Ancestro fasse plein de messages d'erreur, donc pas d'optimisation possible.
Il y a sans doûte d'autres boucles. Une leçon qu'on pourrait tirer de ton expérience, mais je ne sais pas si les généalogistes seront d'accord, c'est qu'il est préférable de mettre une date estimée pour la naissance ou le décès , ainsi les contrôles de cohérences, auraient plus de chances de trouver les anomalies de bouclage, et il y aurait moins de risques de confusion d'individus lors de la sélection.
A+
André
-
Bonjour,
J'espère que le problème du plantage lors du calcul de consanguinité sur un dossier "à bouclettes" est résolu avec la base b4.014.
Mais pas le problème de la détection des boucles. Le calcul de consanguinité dans ce cas demande de la patience, et est certainement faux.
A+
André
-
J'espère que le problème du plantage lors du calcul de consanguinité sur un dossier "à bouclettes" est résolu avec la base b4.014.
Bonsoir,
J'ai refait un calcul de consanguinité complet sur la base de 13000 individus (j'étais en v450 b4.015). Pas de plantage, résultat obtenu en moins de 1 minute, je m'attendais à beaucoup plus, je n'avais donc pas noté la seconde de départ.
Même si le résultat risque d'être faux si il y a des boucles, je pense que les erreurs éventuelles se produisent avec les individus concernés par la boucle dans la limite des générations mentionnée dans la configuration (j'ai laissé 4).
Encore merci à André dont les investigations et le travail pointilleux ont permis de trouver une solution au problème.
Cordialement
Joël
-
La précision est faible avec 4 générations seulement. Pour une base normale, je fais le calcul sur 10 générations. Comme le calcul n'utilise plus une formule récursive elle ne devrait pas planter le micro, ce n'est qu'une question de temps et de grossissement de la base. Essayez d'augmenter progressivement le nombre de générations, en l'optimisant entre chaque essai, pour mesurer l'impact sur le temps de calcul et la taille de la base. Et une mesure de la somme des consanguinités par la requête:
SELECT SUM(CONSANGUINITE) FROM INDIVIDU, vous permettrait de voir à partir de combien de générations, il n'y a plus d'augmentation significative.
Bonne nuit
André
-
26 000 personnes et 40 générations.
Le calcul se passe bien et se termine dans un temps tout à fait raisonable.