forum Ancestrologie
Ancestrologie - Le Programme => Ancestrologie - Rapports d'anomalies => Discussion démarrée par: Horemans le 24 Novembre 2005 à 22:12:18
-
Question qui n'est j'espère, pas liée directement à Ancestrologie.
Quand je soumets mon gedcom à un programme de controle extérieur, j'obtiens le message suivant que je ne comprends pas car je ne trouve pas d'anomalie dans Ancestrologie.
Two FAM records appear to be identical.(The person is married twice, while these marriages can not be distiguished or it can not be determined which marriage came firt)
INDI I2129 Michèle Eugénie Lagnez
SEX F
BIRT 4 APR 1937 Thuin, Belgique
FAMC F5131 BIRT
FAMS F836
FAMS F837
FAMS F838
Details of the FAMS reference :
FAM F837
HUSB unknow
WIFE I2129 Michèle Eugénie Lagnez
Details of the FAMS reference :
FAM F836
HUSB unknow
WIFE I2129 Michèle Eugénie Lagnez
Je précise que j'ai bien un mari et une femme dans l'union, qu'aucun des 2 n'est polygame ni remarié.. Un mariage simple.
J'ai 5 cas structurés de la même façon.
-
N'y aurait-il pas 2 evenements mariages saisis pour distinguer le religieux du civil, comme il en a été question il y a quelques temps ?
Ce n'est qu'une idée
-
Parmi les messages disparus :cry:
Il était évoqué des unions fictives dans la base ancestrologie. J'avais a l'époque sauvé (ou trouvé sur un site) cette procédure SQL permettant de retrouver celles-ciSELECT I.NOM , I.PRENOM ,I.CLE_FICHE AS NIP , T.UNION_CLEF AS CLE_UNION
FROM T_UNION T, INDIVIDU I
WHERE T.KLE_DOSSIER = 13
AND I.CLE_FICHE = T.UNION_MARI
AND T.UNION_FEMME IS NULL
AND T.UNION_CLEF NOT IN (SELECT EV_FAM_CLEF FROM EVENEMENTS_FAM)
AND T.UNION_MARI NOT IN (SELECT CLE_PERE FROM INDIVIDU )
UNION
SELECT I.NOM , I.PRENOM ,I.CLE_FICHE AS NIP , T.UNION_CLEF AS CLE_UNION
FROM T_UNION T, INDIVIDU I
WHERE T.KLE_DOSSIER = 13
AND I.CLE_FICHE = T.UNION_FEMME
AND T.UNION_MARI IS NULL
AND T.UNION_CLEF NOT IN (SELECT EV_FAM_CLEF FROM EVENEMENTS_FAM)
AND T.UNION_FEMME NOT IN (SELECT CLE_MERE FROM INDIVIDU )
-
Pour Bruno :
Pas de mariage religieux pour moi autrement que dans les notes. Merci
Pour Gilles :
Très bien cette requête que j'ai du oublier ou ne pas voir.
Elle me permet de trouver un de mes 5 cas qui se ressemblent pourtant, mais un seul.
Il y a peut-être une variante.
çà confirme mon sentiment d'une erreur d'Ancestro.
Dans quel contexte ces unions bidons ont-elles pu être créees : mystère
En attenedant, même Visuged n'a pas détecté ces anomalies. :evil:
-
Dans le gedcom, après:
FAM F837
HUSB unknow
WIFE I2129
il n'y a pas d'enfants?
A+
André
-
Dans ce cas précis il n'y a pas d'enfant, mais il y en a dans 3 cas sur 5. A chaque fois, j'ai 2 liens FAMS de plus que d'unions. (4 pour deux unions successives). (Edit : J'avais écrit FAMC, c'est FAMS qu'il faut lire)
Le cas est relativement rare dans ma base, 5 cas sur près de 2000 unions, il s'agit peut-être de la trace d'une anomalie ancienne et corrigée depuis.
Je conserve ces cas pour une analyse plus fine, mais je ne suis pas un spécialiste du gedcom.
-
Dans les 3 cas sur 5, les enfants ont-ils pour père l'époux de Michèle. Comme on l'a dit sur un autre fil, une union borgne est créée si l'épouse a un enfant sans père, mais cette union devrait disparaître si le père "reconnait" tous les enfants. Cà devrait aussi se voir dans le gedcom après chaque étiquette FAM , il y a l'époux, l'épouse et les enfants.
A+
André
-
J'ai un cas sans enfants (jeunes mariés)
Un cas d'une femme remariée avec enfants de chaque côté mais 4 liens FAMS
Les autres cas avec plusieurs enfants tous du même père.
J'ai fait un test sur le jeune couple :
1) j'ai supprimé le marriage : l'anomalie reste strictement la même : 3 FAMS
2) J'ai supprimé l'union : le FAMS valide a disparu, restent les 2 FAMS causes de l'ano
Je corrige une erreur dans mon message plus haut, il fallait lire FAMS et non FAMC
-
Peux-tu faire la requête présentée parGilles ci-dessus, en supprimant tour à tour chacune des lignes
AND T.UNION_CLEF NOT IN (SELECT EV_FAM_CLEF FROM EVENEMENTS_FAM)
AND T.UNION_FEMME NOT IN (SELECT CLE_MERE FROM INDIVIDU )
Tu pourras peut-être trouver des unions où il y a un évènement familial non visible de la fiche puisque l'un des conjoint est absent?
A+
André
-
En enlevant uniquement la dernière ligne
AND T.UNION_FEMME NOT IN (SELECT CLE_MERE FROM INDIVIDU )
Il me reste 29 lignes dont 4 doubles correspondant aux 4 ano qui me restent (j'ai séparé le jeune couple pour tests)
Seules les 4 anos présentent des lignes doublées
Si j'enlève l'autre ligne de la requête, j'ai alors 32 lignes, y compris les 4 anos
Votre avis.. docteur ?
-
J'ajoute que pour chque ligne, la valeur de cle_union correspond aux 2 valeurs qui sont rejetées.
et comment je vois si ces évènement correspondent à un événement non visible de la fiche ?
Les 2 lignes sont de ce type. ce que je voudrais trouver, c'est pourquoi ces événements sont là
-
Je viens de m'apercevoir qu'il y a une erreur dans la requête de Gilles, on ne doit pas rechercher si T.UNION_CLEF est dans EV_FAM_CLEF mais dans EV_FAM_KLE_FAMILLE.
Par contre celle-ci devrait marcher(je l'espère)SELECT I.NOM , I.PRENOM ,I.CLE_FICHE AS NIP , T.UNION_CLEF, T.KLE_DOSSIER AS DOSSIER
FROM T_UNION T, INDIVIDU I
WHERE T.UNION_CLEF NOT IN (SELECT EV_FAM_KLE_FAMILLE FROM EVENEMENTS_FAM) AND
((I.CLE_FICHE = T.UNION_MARI
AND I.CLE_FICHE NOT IN (SELECT CLE_PERE FROM INDIVIDU )
AND T.UNION_FEMME IS NULL )
OR(I.CLE_FICHE = T.UNION_FEMME
AND I.CLE_FICHE NOT IN (SELECT CLE_MERE FROM INDIVIDU )
AND T.UNION_MARI IS NULL ))Par curiosité j'ai aussi faitselect EV_FAM_CLEF FROM EVENEMENTS_FAM
where EV_FAM_KLE_FAMILLE NOT IN(select UNION_CLEF FROM T_UNION)Là j'ai trouvé un évènement familial non lié à une union: pas normal!. J'avais trouvé une procédure qui supprimait un évènement familial d'une union autre que celle que l'on supprimait (réparé dans la b4.00), mais pas le cas inverse.
Les mises à jour ne sont pas terminées...
A+
André
PS: ce cas est surement un reste d'avant b4.00, car j'y ai ajouter un triger qui supprime les évènement familiaux liés à une union quand on supprime l'union.
-
Avez-vous essayé l'option "Correction des incohérences sur individu" dans le menu Configuration. Normalement celà effectue des controles dans la base et signale des anomalies. Chez moi, je ne peux pas dire si çà marche puisque la main m'est rendue immédiatement après que j'ai cliqué sur le bouton "Oui" d'un avertissement "Cette action risque de durer plusieurs minutes - Voulez-vous continuer?". Est-ce parce qu'il n'y a pas d'incohérence? Je n'ai aucun message.
Je pense que cette option appelle la procedure PROC_INCOHERENCES que l'on peut activer dans le BOA par:
select * from PROC_INCOHERENCES(dossier,mode) où mode=0 pour lister les incohérences ou 1 pour supprimer les enregistrement anormaux.
Mais le test sur les évènements familiaux sans union n'y est pas fait. Je le rajouterai dans la b4.005
A+
André
-
Bonsoir,
André, j'ai le même problème que toi :
Chez moi, je ne peux pas dire si çà marche puisque la main m'est rendue immédiatement après que j'ai cliqué sur le bouton "Oui" d'un avertissement "Cette action risque de durer plusieurs minutes - Voulez-vous continuer?". Est-ce parce qu'il n'y a pas d'incohérence? Je n'ai aucun message.
J'ai la version v370 b3.57, Windows XP SP2 familiale et j'ai toujours constaté ça même avec les versions précédentes.
Joël
-
Bonsoir,
André, j'ai le même problème que toi :
Chez moi, je ne peux pas dire si çà marche puisque la main m'est rendue immédiatement après que j'ai cliqué sur le bouton "Oui" d'un avertissement "Cette action risque de durer plusieurs minutes - Voulez-vous continuer?". Est-ce parce qu'il n'y a pas d'incohérence? Je n'ai aucun message.
J'ai la version v370 b3.57, Windows XP SP2 familiale et j'ai toujours constaté ça même avec les versions précédentes.
Joël
J'avais, il y quelques mois demandé sur le forum ce que faisait cette fonction, car effectivement je trouvais que la main m'était très (trop) rapidement pour un test de cohérence.
Je n'ai eu aucune réponse satisfaisante :cry:
-
Bonjour,
Il me semble que lorsque j'ai essayé cette fonction il y a quelques versions d'Ancestrologie, une fenêtre demandait si on voulait vérifier ou corriger les incohérences. Maintenant, plus rien!
Si quelqu'un pouvait essayer une ancienne version pour confirmer?
Je pensais que cette fonction utilisait la procédure PRO_INCOHERENCES (que Laurent doit bien connaître, c'est lui qui l'a faîte).
Mais je viens de vérifier que non (j'ai créé une table TRACES, et modifié la procédure pour qu'elle y écrive un enregistrement).
En attendant, la procédure peut être lancée depuis un requêteur comme je l'ai dit ci-dessus.
Elle est trop longue pour que j'en mette tout le texte ici, voici seulement un extrait permettant d'identifier le contrôle effectué et la table concernée:
O_LIBELLE='Adresse pointant sur un individu inexistant';
O_TABLE='adresses_ind';
O_LIBELLE='Table divers pointant sur un individu inexistant';
O_TABLE='divers';
O_LIBELLE='Evénement individu pointant sur un individu inexistant';
O_TABLE='evenements_ind';
O_LIBELLE='Source_pointeurs pointant sur un individu inexistant';
O_TABLE='source_pointeurs';
O_LIBELLE='union pointant sur un mari inexistant';
O_TABLE='t_union';
O_LIBELLE='union pointant sur une épouse inexistante';
O_TABLE='t_union';
O_LIBELLE='Media Pointeurs pointant sur un individu inexistant';
O_TABLE='media_pointeurs';
O_LIBELLE='Doublons pointant sur un individu inexistant';
O_TABLE='t_doublons';
O_LIBELLE='Association pointant sur un individu inexistant';
O_TABLE='t_associations';
O_LIBELLE='Associé d une association pointant sur un individu inexistant';
O_TABLE='t_associations';
O_LIBELLE='Association pointant sur un événement familial inexistant';
O_TABLE='t_associations';
O_LIBELLE='Père présent dans la fiche individu mais inexistant';
O_TABLE='individu';
O_LIBELLE='Mère présente dans la fiche individu mais inexistante';
O_TABLE='individu';
O_LIBELLE='Enfant dont les parents n ont pas d union dans la table T_UNION';
O_TABLE='individu';
et je comptais y ajouter:
O_LIBELLE='Evénement familial pointant sur une union inexistante';
O_TABLE='EVENEMENTS_FAM';
O_LIBELLE='Association pointant sur un événement individuel inexistant';
O_TABLE='t_associations';
En mode 0, les enregistrements anormaux sont listés
En mode 1, en plus ils sont supprimés.
A+
André
-
select * from PROC_INCOHERENCES(3,0)
Ne donne pas plus de résultat dans le BOA que directement par Ancestrologie.
select EV_FAM_CLEF FROM EVENEMENTS_FAM
where EV_FAM_KLE_FAMILLE NOT IN(select UNION_CLEF FROM T_UNION)
Me donne 14 valeurs de EV_FAM_CLEF qu'il va falloir que j'analyse.
SELECT I.NOM , I.PRENOM ,I.CLE_FICHE AS NIP , T.UNION_CLEF, T.KLE_DOSSIER AS DOSSIER
FROM T_UNION T, INDIVIDU I
WHERE T.UNION_CLEF NOT IN (SELECT EV_FAM_KLE_FAMILLE FROM EVENEMENTS_FAM) AND
((I.CLE_FICHE = T.UNION_MARI
AND I.CLE_FICHE NOT IN (SELECT CLE_PERE FROM INDIVIDU )
AND T.UNION_FEMME IS NULL )
OR(I.CLE_FICHE = T.UNION_FEMME
AND I.CLE_FICHE NOT IN (SELECT CLE_MERE FROM INDIVIDU )
AND T.UNION_MARI IS NULL ))
cette requête retrouve 2 de mes erreurs gedcom et 2 lignes par cas
Mais en plus j'ai une ligne seule concernant un individu isolé sans lien avec quiconque (hors son patronyme connu), que j'ai placé là à cause de sa signature très lisible sur un acte alors qu'il n'est même pas cité comme témoin. Pourquoi sa présence dans une table concernant les unions?
Ces erreur ne sont pas une très grande gêne pour moi, mais çà peut cacher des choses plus sérieuses.
-
La requête 1 ne donne pas de résultat: c'est pour celà que je voudrais ajouter la requête 2 à la procédure pour qu'elle détecte les evènements familiaux sans union.
Requête 2: refait-là avec select * aulieu de EV_FAM_CLEF, çà permettra au moins de voir le type d'évènement et sa date, parce que ce sont les seuls renseignements qui permettront une recherche; l'union n'existant plus, on ne peut connaître les époux. Pour mon EF sans union, j'ai trouvé un autre EF de mêmes type et date. Mais pourquoi, a-t-il été créé ou n'a-t-il pas été supprimé?
Requête 3: elle donne les individus des unions avec conjoint seul, sans évènement familial et sans enfant. Mais comment peux-tu avoir 2 lignes par cas s'il n'y a qu'un individu dans l'union? C'est 2 fois le même individu avec des unions différentes?
Est-ce que çà peut cacher des choses plus sérieuses? J'espère que non. Mais en l'absence de règle d'intégrité et de contraintes intégrées à la base (ex: une union doit être créée avant l'évènement familial qui y est rattachée et la suppression de l'union entraîne celle de l'EF), on ne peut que faire confiance au programme(eur).
A+
André
-
Requête 2 : concerne uniquement des tag MARR, pas de repère permettant de cerner la date de saisie de ces événements. Je gratte encore un peu.
Requête 3 : J'ai 2 lignes qui pour moi correspondent au 2 tags FAMS excedédentaires de mon gedcom et correspondant à chaque fois à 2 unions fictives. Mes individus sont bien mariés mais tout se passe comme si il y avait 2 unions de plus que la vraie et sans mari(sans HUSB) d'ou 3 tags FAMS.
Je peux transmettre mon gedcom à un spécialiste si nécessaire.
-
A ta place je commencerai par supprimer les unions sortie par la requête 3 parce qu'ells ne devraient pas exister (sur une copie de la base par prudence) par des
DELETE FROM T_UNION WHERE UNION_CLEF= XXX.
Ensuite je supprimerai les EF en trop par un
DELETE FROM EVENEMENTS_FAM
where EV_FAM_KLE_FAMILLE NOT IN(select UNION_CLEF FROM T_UNION)
puis passerai la requête de contrôle de cohérence:
select * from PROC_INCOHERENCES(dossier,mode) avec mode=1 pour supprimer certaines autres incohérences de la base.
Et pour terminer (en espérant qu'il reste quelque chose :wink: ) faire un export gedcom pour voir s'il présente encore des anomalies.
A+
André
-
1) Dans le couple que j'avais séparé et ou l'ano persistait, j'ai supprimé puis recréé l'individu et l'union : l'ano a disparu du gedcom
2) DELETE FROM T_UNION WHERE UNION_CLEF= XXX
L'ano détectée par la requête 2 à disparu du gedcom
Mais pourquoi les 3 autres ano parfaitement similaires ne sont-elles pas visibles par cette requête ?
3) DELETE FROM EVENEMENTS_FAM where EV_FAM_KLE_FAMILLE NOT IN(select UNION_CLEF FROM T_UNION)
Les éléments que la requête trouvait ont bien disparu mais mais ano sont toujours là
4) select * from PROC_INCOHERENCES(3,1) me renvoie 2 lignes avec le message suivant :
Enfants dont les parents n'ont pas d'union dans la table T_UNION. Le mode =0 n'affichait rien.
Et mon gedcom présente toujours les 3 anomalies restantes.
Poutant il y a bien une anomalie créée à la génération du gedcom, on devrait pouvoir trouver ce qui provoque la création de 3 tags FAMS alors qu'il n'y a qu'une famille pour l'individu. Et si c'est la génération du gedcom qui est en cause, pourquoi pas dans tous les cas. Qu'est-ce qui distingue ces individus par rapport au reste de la base ? çà dépasse mes compétences.
Avant de supprimer et recréer ces individus, je laisse en l'état s'il y a besoin d'y revenir.
-
Va falloir changer de maxime: Plus çà va plus je m'arrache les cheveux :cry:
A+
André
-
Et comme j'en ai déjà plus beaucoup, faut que j'arrête ! :lol:
En fait, ce n'est peut-être qu'un reste d'une version passée.
Merci pour ta patience.
-
Je viens d'avoir un problème qui ressemble au tien. Lors de l'importation dans KStableau de mon gedcom, j'ai eu le message "mari inconnu pour la famille Fxxx" (en anglais bien sûr...). En ouvrant le gedcom, j'ai vu que cette famille était effectivement déclarée, une épouse pas d'enfant et un mari identifiant =0. J'ai vérifié que dans la table T_UNION, cette union existe bien.
Deux problèmes:
1 - pourquoi cette union est-elle créée par Ancestrologie?
2 - pourquoi dans le code prévoit-on que dans le cas d'un union uni-parentale , le conjoint absent puisse avoir pour code NULL ou zéro, puisque le zéro est exporté à tort dans le gedcom?
Pour cette deuxième raison, le conjoint à 0 n'est pas éliminé dans la procédure incohérences.
J'ai supprimé cette union de ma base (en mode accès direct aux tables). Je n'ai plus d'erreur d'importation du gedcom dans KStableau.
Pourrais-tu voir si tu n'a pas ce problème dans ta base?
select * from T_UNION where UNION_MARI=0 or UNION_FEMME=0 dans le BOA ou recherche des Fxxx dans le gedcom
Tu devrais déjà voir si les familles qui te donnent des problèmes. S'il n'y a pas d'enfants, l'union peut être supprimée, sinon remplacer le 0 par NULL.
A+
André
-
On ne doit pas être sur le même cas car
select * from T_UNION where UNION_MARI=0 or UNION_FEMME=0
ne donne aucun résultat en sortie.
Dans le gedcom je retrouve bien les FAMS avec des N° Fxxx qui renvoient au lien FAM Fxxx associé à HUSB unknow
Et çà, 2 fois en plus de l'union normale, pour ces dames qu'Ancestrologie s'évertue à faire passer pour polygames.
C'est moi aussi dans KStableau que je trouve ces contrôles pointus.
Dodo
-
Bonjour,
Si tu as trouvé le FAM Fxxx avec HUSB Iyyy unknow, avec
select * from T_UNION where UNION_CLEF=xxx
tu dois tout retrouver.
Eventuellement rechercher si cette union a un évènement familial ou si yyy est le père d'un enfant, çà pourrai t'aiguiller sur l'origine de l'erreur.
select * from EVENEMENTS_FAM where EV_FAM_KLE_FAMILLE=xxx
select * from INDIVIDU where IND_PERE=yyy
et même
select * from INDIVIDU where IND_MERE=NIP de la mère pour vérifier qu'elle n'a pas d'enfant déclaré sans père.
Si tu ne trouve rien d'anormal, alors tu peux supprimer l'union.
delete from T_UNION where UNION_CLEF=xxx
Quand aux questions: pourquoi c'est arrivé, quand, est-ce que çà peut encore se produire? je suis incapable d'y répondre, et ce qui m'inquiette, c'est que PCM non plus. Il y a dans ancestrologie beaucoup de libertés prises avec les règles d'intégrité, laissant au programmeur le soin de les assurer à chaque écriture. Alors s'il en oublie...
A+
André
-
J'ai suivi à peu près toutes tes propositions.
Dans le gedcom, pour les enreg en ano il n'y a pas de tag HUSB précédant le tag WIFE donc pas de HUSB Iyyy.
Dans T_UNION : la colonne UNION_MARI est vide pour les unions excedentaires
Dans EVENEMENTS_FAM : La plupart du temps, la correspondance la KLE_FAMILLE n'existe pas. quand elle existe. on trouve une date jj/mm/aaaa pour une KLE.. et jj mois aaaa pour une KLE en ano.
J'ai même un cas avec 2 KLE... identiques, l'une avec et l'autre sans date.
et un cas avec une date qui n'a rien à voir avec le couple
Quand je regarde les NIP, ils sont compris entre 1963 et 2552. J'en suis actuellement à 17911, même si depuis quelques temps les numéros s'incrémentent de 2 en 2, ces anomalies sont donc anciennes.
Puisque que j'ai un outil capable de détecter ces erreurs (KStableau), je vais suivre la question, pour voir si on retrouve cette ano à l'avenir, mais j'ai l'impression de chercher un truc qui a été rectifié et qui ne se reproduit plus. Ce serait l'idéal.
Je vais donc épurer par delete from T_Union where UNION_CLEF=xxx
mais il faudra aussi épurer les enreg qui ont une correspondance dans la table EVENEMENTS_FAM. Es-tu d'accord avec celà, n'y a-t-il pas d'autre table concernée
-
Si après tout çà, certains ne comprennent pas ce que je veux dire dans mon petit paragraphe ci-dessus concernant les libertés prises avec les règles d'intégrité!
La suppression d'une union doit entraîner effectivement la suppressions des évènements familiaux, puis en cascade des associations (témoins), des sources_record liés, des media_pointeurs (des liens entre les médias et les individus concernés par cet évènement, par l'acte et les sources). Mais si tu avais fait le basculement en base 4.00, ce serait fait automatiquement à la suppression d'une union.
J'en suis à la version 4.005 téléchargeable maj_b357_b4005.exe (http://andre.langlet.free.fr/ancestro/maj_b357_b4005.exe) pour mettre à jour ta base, base vide et liste de modifications ICI (http://andre.langlet.free.fr/ancestro/FAMILLEVIDE4005.zip).
Dans cette version il y a une PROC_INCOHERENCES que j'ai complètée pour justement supprimer les évènements familiaux sans union et rectifier des unions avec un conjoint sans fiche (plus ce que j'ai présenté hier sur le forum développement pour les témoins). Cette procédure reste utile, car si les triggers que j'ai ajoutés dans la base 4.00 font bien le ménage lors de la suppression d'une union, ils ne réparent pas les erreurs précédentes (évènements sans union...).
A+
André
-
Je tourne déjà avec les bases 4, la 4.005 est en place depuis 10mn.
Je vais l'utiliser pour remettre à niveau... puis ... controler ! :wink:
-
André,
Pourquoi n'as tu pas mis ta nouvelle mouture, soit dans le post développement ou installation mise a jour :wink:
-
André,
Pourquoi n'as tu pas mis ta nouvelle mouture, soit dans le post développement ou installation mise a jour :wink:
Les liens et indications jusqu'à la version b4.004 figurent bien sur le forum installation, et pour les modif depuis, j'ai proposé sur Développements des modifs à incorporer, et j'attendais quelques réponses avant de l'intégrer "semi-officiellement" dans une mise à jour. Bien que n'ayant qu'une seule réponse :cry: et un peu pour dépanner PH, je viens de mettre cette version b4.005 en ligne. Tu peux l'essayer si tu veux.
A+
André
-
C'est fait, je l'ai installé et tout va bien et je posais justement la question si je pouvais passer a la version 3.90 sans crainte d'une mésaventure, qu'en penses tu :wink:
-
Je ne pense pas que tu risques grand chose. Les modifs par rapport à ce que PCM connaissait quand il a fait cette v390, ne doivent rien remettre en cause.
Elles sont listées en fin du fichier modificationsBDD.txt accompagnant la base vide, modifications depuis le 23/11.
A+
André
-
Avec la base 4.005
j'ai 2 ano qui se sont réglées spontanément
Mais la 4.005 ne règle pas tout
J'en ai 2 autres récalcitrantes :
J'ai coupé tous les liens entre les parents et entre les enfants et les 2 parents, suivi d'un gedcom, je ne retrouve pas l'union valide bien sûr, mais les 2 unions erronées sont tjrs présentes.
A chaque fois, l'ano semble liée à la mère, puisque j'ai dans T_UNION
Fam xxx union_mari null et union_femme contenant son nip
Prochain essai : je supprime la femme et je me prends une côte pour la recréer :wink:
-
Opération terminée, je n'ai plus d'ano sur des mariages fantômes. Ce sera plus facile à suivre si çà se reproduit.
Me restent maintenant une série d'anomalie intitulées
"Mariages en désordre"
Le problème et connu et attend toujours une solution.