Merci mais cette manip ne fonctionne pas dans mon cas. Le message d'erreur apparaît une fois, puis quand on clique OK, on a des violations d'accès jusqu'au plantage d'Ancestrologie.
Je m'en suis sorti en remplaçant mon fichier Ancestrologie.bdd par une base vierge. Une fois dans Ancestrologie dans le menu "Configuration", option "Emplacement de la base de données", j'ai rechargé ma base merdique.
Malgré quelques messages déagréables, j'ai eu accès au menu et ai lancé une optimisation de la base. Résultat, j'ai repris la main (tant que je ne consulte pas une fiche avec une date négative tout va bien).
Ensuite je me suis attaqué au problème des dates négatives. Je précise qu'elles sont apparues suite à un export de mes dossiers au format GEDCOM et à un réimport :
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Sous BOA
Considérant que le numéro de dossier de ma base est le 2.
La requête de recherche des dates de naissances/baptèmes négatives :
select CLE_FICHE, NOM, PRENOM, DATE_NAISSANCE, ANNEE_NAISSANCE, EV_IND_DATE_WRITEN
from INDIVIDU I
left outer join EVENEMENTS_IND N on I.CLE_FICHE = N.EV_IND_KLE_FICHE and (N.EV_IND_TYPE= 'BIRT' or N.EV_IND_TYPE= 'CHR')
where I.KLE_DOSSIER =2 and I.ANNEE_NAISSANCE <0
Le résultat est (désolé pas d'indentation) :
CLE_FICHE NOM PRENOM DATE_NAISSANCE ANNEE_NAISSANCE EV_IND_DATE_WRITEN
2254 VIMONT François -1605 -1605 -1605
2900 TETREL Marie Marguerite -1720 -1720 -1720
3469 SERY Anthoine -1714 -1714 -1714
4054 HAUCHECORNE Susanne -1695 -1695 -1695
4296 DÉHAIS Nicolas -1675 -1675 -1675
4697 RECHER Catherine -1720 -1720 -1720
Seulement voilà, la table individu ne contient pas la véritable date de naissance, les champs de date de cette table servent à l'affichage des listes d'individus (c'est pas propre Mr Cazaux-Moutou !).
La table qui stocke les dates de naissance est la table EVENEMENTS_IND :
La requête de recherche de la table contenant la date de naissance/baptème complète de VIMONT François est :
select EV_IND_KLE_FICHE,EV_IND_TYPE, EV_IND_DATE_WRITEN, EV_IND_DATE_YEAR
from EVENEMENTS_IND
where EV_IND_KLE_DOSSIER =2 and (EV_IND_TYPE= 'BIRT' or EV_IND_TYPE= 'CHR') and EV_IND_KLE_FICHE =2254
EV_IND_KLE_FICHE EV_IND_TYPE EV_IND_DATE_WRITEN EV_IND_DATE_YEAR
2254 BIRT -1605 -1605
En consultant des individus ayant une date de naissance/baptème complète (ce n'est pas le cas dans le cas présent),
on en conclue que le champ stockant la date de naissance/baptème est EV_IND_DATE_WRITEN. (WRITTEN s'écrit avec deux "T" Mr le programmeur)
Pour chacune des fiches, on va remettre la date de naissance négative en date positive ;
update EVENEMENTS_IND set EV_IND_DATE_WRITEN = 1605 where EV_IND_KLE_DOSSIER=2 and EV_IND_KLE_FICHE=2254 ;
update EVENEMENTS_IND set EV_IND_DATE_WRITEN = 1720 where EV_IND_KLE_DOSSIER=2 and EV_IND_KLE_FICHE=2900 ;
update EVENEMENTS_IND set EV_IND_DATE_WRITEN = 1714 where EV_IND_KLE_DOSSIER=2 and EV_IND_KLE_FICHE=3469 ;
update EVENEMENTS_IND set EV_IND_DATE_WRITEN = 1695 where EV_IND_KLE_DOSSIER=2 and EV_IND_KLE_FICHE=4054 ;
update EVENEMENTS_IND set EV_IND_DATE_WRITEN = 1675 where EV_IND_KLE_DOSSIER=2 and EV_IND_KLE_FICHE=4296 ;
update EVENEMENTS_IND set EV_IND_DATE_WRITEN = 1720 where EV_IND_KLE_DOSSIER=2 and EV_IND_KLE_FICHE=4697 ;
A chaque requête exécutée, j'ai eu une violation d'accès sur le module DLL_BOA.dll, mais la mise à jour est malgré tout exécutée sans perte d'information.
Des procédures stockées ont certainement synchronisé la valeur des champs DATE_NAISSANCE, ANNEE_NAISSANCE des tables EVENEMENTS_IND et INDIVIDU avec la valeur mise à jour EV_IND_KLE_FICHE de la table EVENEMENTS_IND
Cliquer sur le bouton "valider les modifications"
Cette procédure doit être valable pour des événements-individu de type décès (DEAT) et inhumation (BURI).
Au final, j'ai de nouveau une base utilisable avec un Ancestro qui ne plante pas plus que d'habitude. Ouf !
Accueil
Aide
Rechercher
Identifiez-vous
Inscrivez-vous
