Décès renseigné à tort

[LOBENI]

Bonjour.

J'ai renseigné à tort une date et un lieu de décès pour une personne qui ne l'est pas encore (erreur de fiche).

J'ai donc supprimé les informations sur la fiche concernée.

Mais problème : l'événement apparaît toujours dans la liste proposée des actes manquants (liste sélective "il-me-manque-l'acte"), comme si les renseignements restaient mémorisés.

Comment puis-je résoudre le problème ?

Merci par avance de votre réponse.

 

[michel13]

Bonjour à tous,

Cela semble, sauf erreur, lié à cette fameuse base centrale qui sait incrémenter mais refuse de décrémenter les données d'une manière simple.
Une solution, sans risque, pourrait consister à aller dans l'onglet "Complément", à coté de "Fiche" en bas de l'écran, de cliquer sur "supprimer des rubriques" et de supprimer la rubrique "Décès" de la fiche. Cela ne supprime que le contenu de la rubrique dans la base centrale.
Donc rassurer vous la fiche reste intact mais la rubrique "Décès", toujours existante, devrait alors être vide pour la base centrale.

 

[dfx]

bonjour
Pour que la liste (il-me-manque-l'acte) soit correcte il faut que les champs 'date' et 'lieu' soient renseignés et bien-sûr que le champ 'Acte' soit vide.
Cad que s'il manque la date OU le lieu vous ne l'aurez pas dans la liste.
Aucun lien avec le problème des champs booléens

 

[LOBENI]

Bonsoir.

La solution proposée par Michel13 a solutionné mon problème.
Merci pour les réponses.

LOBENI

 

[michel13]

Bonsoir à tous,

Comme l'avait dit LOBENI, il avait supprimé la date et le lieu et cela semblait mémorisé.
De par sa conception la base de donnée centrale sait incrémenter les quantités de données mais ne sait pas les décrémenter.
Une fiche est composée, entre autre, de divers champs et de rubriques comprenant plusieurs champs naissance, union, décès etc qui apparaissent dans la fonction "Détruire des rubriques" de l'onglet Compléments.
Si on ouvre une fiche la base de données centrale ne crée ces champs et ces rubriques qu'au fur et à mesure qu'on les remplit.
Donc au niveau de la base centrale ces entités n'existent pas (état 1) ou existent parce qu'elles sont ou ont été remplies (état 2). Si elles ont été vidées dans la fiche elles sont vides dans la base mais pour la base le statut "vide" correspond strictement à "n'existe pas" (n'a pas encore été créé ou a été détruit). Si l'entité est vide mais non détruite elle reste à l'état 2.
Si on les remplit dans la fiche la base les crée mais si on les vide dans la fiche la base les vides mais ne sait pas les détruire et conserve donc leur structure. Les fonctions statistiques continuent donc sournoisement de les prendre en compte.
Or l'algorithme de la liste "Il_me_manque_l'acte" fait appel à des entités vides et non vides d'où le problème.
Le seul moyen de les faire disparaître de la base centrale c'est d'aller les y détruire manuellement.
C'est ce que l'on fait avec la fonction "Détruire des rubriques" de l'onglet Compléments.
A l'origine cela aurait été conçu pour économiser de la place en mémoire (les champs vides n'existant pas en mémoire) et par conséquent accélérer le fonctionnement du logiciel.
Mais cela pose aux utilisateurs d'énormes problèmes de gestion des données car pour détruire la rubrique gênante après avoir quitter la fiche vidée depuis quelques temps ce n'est pas toujours aussi facile que cela paraît : il faut en effet retrouver à la fois la fiche incriminée et l'entité défaillante. Dans certains cas cela se révèle inextricable à terme car rien ne distingue une entité vide d'origine d'une entité vide qui n'a pas été détruite dans la base de données.
En fait il ne faut jamais vider l'une de ces entités dans la fiche mais il faut aller directement la détruire dans l'onglet complément.
Je connaissais le problème pour certains champs de type booléens (signatures, jumeaux et autres) mais je ne pensais pas qu'il était aussi associé aux rubriques naissances, unions, décès et autres.
Comme je viens de le tester cela concerne en fait toutes les entités figurant dans la fonction "Détruire des rubriques" de l'onglet Compléments.
Il est dommage que ceci ne figure pas de façon explicite dans l'aide.

Je regrette beaucoup, dfx, mais ce problèmes des "variables booléennes à trois états" est beaucoup plus gênant (pour ne pas dire grave) que le CDIP ne veut l'admettre et on le retrouve à tout bout de chemin.

 

[dfx]

Nous avons déjà parlé de cette anomalie à propos des champs booléens et je suis d'accord avec vous michel13, c'est génant. Bien que contournable en connaissant cette anomalie, c'est néanmoins une réelle anomalie.

Mais en ce qui concerne le sujet courant, là je ne vous suis plus michel13.
J'ai fait des tests en renseignant/effacant les données des champs Acte, Date, Lieu dans toutes les combinaisons possibles et sans aller dans 'Supprimer une rubrique' or tout fonctionne correctement.
Seul le cas des champs 'Date' et 'Lieu' renseignés donne une ligne de dans le modèle "Il-me-manque-l'acte", dans tous les autres cas aucune ligne et ceci après de multiples manipulations des ces champs.
Et tout ceci est conforme aux conditions d'origine décrites dans le modèle. Je ne retrouve pas le contexte de votre démonstration dans mes tests.

Pour revenir au cas de LOBENI, je ne peux expliquer cette anomalie. Sa disparition est bien-sûr la conséquence de l'utilisation de la fonction 'Supprimer une rubrique'. Mais cette façon de faire est pratiquement impossible a réaliser sur une base de données conséquentes et sera toujours un sujet de doute quant à la fiabilité des listes produites.

J'aimerais savoir si vous (michel13) avez testé ce modèle et constaté l'anomalie, car si elle s'avère présente, elle l'est aussi sur tous les modèles dont les conditions font appel à Vide / Non Vide et là c'est effectivement plus que génant, c'est grave et il conviendrait que le CDIP se penche sans tarder sur le problème

 

[michel13]

Bonjour à tous,

J'ai tardé à répondre car comme vous, dfx, j'ai voulu reproduire le cas LOBENI.
Les tests cités dans mon précédent message concernaient les rubriques apparaissant dans compléments, "suppression des rubriques", qu'il faut détruire pour les réinitialiser et les sortir des statistiques, mais pas leurs "champs".

Pour le cas qui nous préoccupe je suis d'accord avec vous, dfx, que pour avoir une demande d'acte il faut et il suffit de remplir les champs "date" et "lieu" de la rubrique considérée.
Or LOBENI a écrit :

". . . . J'ai donc supprimé les informations sur la fiche concernée.
Mais problème : l'événement apparaît toujours dans la liste proposée des actes manquants (liste sélective "il-me-manque-l'acte"), comme si les renseignements restaient mémorisés"

Il avait effacé les données des champs et la demande d'acte persistait. Cette demande imposant que les champs date et lieu soient renseignés, pour moi ils étaient effacés dans la fiche mais intacts dans la base. D'où ma proposition. Qui a marché.
La demande ayant disparu en supprimant la rubrique on peut supposer que j'avais vu juste.
Or la date et le lieu ne sont pas des rubriques mais les champs d'une rubrique dont le contenu dans la base devrait être en phase avec celui de leurs homologues dans la fiche (Pas d'informations du CDIP sur ce sujet à ma connaissance).
J'ai testé avec soin le modèle et comme vous je n'ai pu reproduire l'anomalie. C'est grave car cela sous tend un caractère aléatoire.
Vous aviez donc raison aussi dfx. Cela n'avait, à priori, aucun lien direct avec le problème des champs booléens. Quoique . . . ils sont quand même gérés par la même base.
En contrôlant rapidement la liste LOBENI a pu constater l'anomalie mais il est probable que d'autres n'aient rien vu car quelques noms en trop dans une telle liste passent inaperçus.

Il semble, dfx, que nous en soyons tous les deux au même point et que nos investigations nous montrent, grâce à LOBENI, que cela peut se produire sans savoir ni quand ni comment ni même si c'est limité au modèle en question. Et nous ne pouvons aller plus loin.
Cela induit un doute et ma proposition pour vider une rubrique dans la base reste d'actualité.

Je reste ouvert à une explication plausible de cette anomalie qui pourrait permettre de lever le doute introduit par cette base quant à la fiabilité des listes produites.

 

[dfx]

Merci pour votre réponse Michel13

... permettre de lever le doute introduit par cette base quant à la fiabilité des listes produites

Nous sommes sur le même longeur d'onde, ce doute latent est bien ennuyeux.
Je souhaiterai savoir si LOBENI a reproduit cette anomalie depuis.

 

[michel13]

Bonjour à tous,

En complément on touve en page 30 de l'aide le texte suivant :

Supprimer des rubriques
Cette fonction permet d???effacer le contenu d???une rubrique. Si cette rubrique se trouve dans l???onglet Compléments, vous supprimerez également l???affichage de ce champ.

Mais nulle part il est écrit qu'il faut utiliser impérativement cette fonction pour effacer le contenu de deux champs d'une rubrique.

 

[michel13]

Bonjour à tous,

En complément à nos investigations voici, dfx, le RC de l'aventure qui vient de m'arriver.
J'ai un champ "Enfant" avec choix.
En contrôlant ce champ dans le dictionnaire je trouve en plus des enfants "reconnu et légitimé" un enfant "reconnu et légitimé itimé" (?????. . . ).
Plusieurs "Recherche et remplacement" en supprimant " itimé" ne change rien.
Une restructuration ne change rien.
L'écran indiquant la fiche je vais sur celle-ci et vide le champ. Retour au dictionnaire, l'enfant a disparu !
Contrôle de la structure du fichier dans les "préférences" le texte du champ "Enfant" est bien "reconnu et légitimé".
De retour dans la fiche je choisis à nouveau "reconnu et légitimé" et dans le dictionnaire j'ai à nouveau un enfant "reconnu et légitimé itimé".
Cette fois, fidèle à mes solutions, je retourne dans la fiche puis je fais "compléments", "supprimer des rubriques", sélection "Enfant", "suppression".
Au retour sur fiche je sélectionne "reconnu et légitimé" et j'ai enfin "reconnu et légitimé" pour cette fiche dans le dictionnaire !
Cela aurait-il une corrélation avec le cas LOBENI ?

 

[dfx]

Cet avatar apporte de l'eau à votre moulin concernant la suppression de la rubrique dans l'onglet complément.

Je ne sais pas si ce cas est celui de LOBENI, d'ailleurs il ne s'exprime plus !
J'ai reproduis votre anomalie, une intuition d'ancien informaticien rattrapé par la retraite mais avec quelques restes !

Avant tout une remarque, on ne peut pas passer par le dictionnaire des données pour modifier un item d'une liste de choix, car cette liste est définie dans la structure de la base de données et sauf a modifier cette structure impossible de faire autrement sinon la cohérence n'est plus assurée.

Justement je pense que vous avez en premier défini dans la structure un item "enfant reconnu et légitimé" que vous avez utilisé, puis en seconde manip vous avez modifié cet item par "reconnu et légitimé" que vous avez aussi utilisé.
Ai-je raison ?

J'ai fait cette opération et j'ai obtenu dans le dictionnaire des données .... "reconnu et légitimé itimé".
Explication: vous avez remarqué qu'il n'y a pas de nb de caractères à une rubrique 'liste de choix', celle ci est définie par le nb de car. du plus grand item et non par un caractère spécial de fin de chaîne de caractère ('\0 en language C')
Si vous réduisez l'item par modification de structure par ex. en passant de "enfant reconnu et légitimé" à "reconnu et légitimé" vous ne changer rien dans l'ancien item plus utilisé ("enfant reconnu et légitimé") de la fiche peu importe puisqu'il n'existe plus, enfin n'est plus utilisé, on dit pointé.
Or le dictionnaire des données permet, a tort, de visualiser les items utilisés mais ne connait pas la longueur maxi de cette liste de choix, d'ailleurs il ne sait même pas que c'est une liste, donc il affiche tous les caractères jusqu'à trouver un caractère de fin de chaîne, l'ancien de "enfant reconnu et légitimé" et vous obtenez : "reconnu et légitimé itimé".

Par contre si on passe par suppression de rubriques, ces données sont effectivement effacées de la zone concernée, là vous avez bien vu.

Je ne sais pas si j'ai été clair, c'est assez difficile à expliquer, mais je suis à peu près sûr de moi quant à l'explication.

Dans ce cas précis de la liste de choix, on ne peut pas appeler ça un bug, le bug c'est de proposer ce type de champ dans le dictionnaire des données notamment pour une modification.

Ouf c'est fini !!!

 

[michel13]

Bonsoir à tous,

Là, fdx, ce n'est plus une réponse, c'est un véritable cours et je vous en remercie.

Je ne me rappelle plus exactement ce que j'ai écrit au départ dans les différents items de la liste mais vous avez tout à fait raison sur le fond. Pourtant en sélectionnant l'item "vide" l'enfant a disparu du dictionnaire et cela n'a pas supprimé le texte " itimé" en fin de l'item, sans doute parce que cet item"vide" ne recouvre que l'item le plus long sans annuler véritablement le texte existant et que le dictionnaire ne travaille qu'avec les premiers caractères de l'item pour savoir s'il est ou non vide.
C'est pourquoi en remettant en place la valeur initiale j'ai retrouvé comme avant l'enfant hors norme et qu'il m'a fallut supprimer la rubrique pour que tout rentre dans l'ordre.
C'est une gestion bizarre qui laisse planer un doute, comme le cas LOBENI, en montrant qu'il peut rester des données dans des items "vidés".
Et bien sûr le dictionnaire n'y est pour rien car il lui faudrait la liste des items pour faire un changement !

 

[Michel P.]

Bonsoir,

C'est une gestion bizarre qui laisse planer un doute, comme le cas LOBENI, en montrant qu'il peut rester des données dans des items "vidés".

Qui n'a jamais été heureux que Windows n'efface pas le contenu d'un fichier quand on le supprime?????
Comme le DOS avant lui, quand on supprime un fichier sous Windows, le fichier n'est pas effacé. Le système se contente de marquer l'entrée de la FAT comme étant effacée et les secteurs sont libérés mais pas effacés. De la sorte, à condition de ne pas avoir manipulé trop de fichiers, on peut récupérer un fichier supprimé.
A mon sens, il n'y a aucune bizarrerie la-dedans.

Par contre, je vois comme une anomalie dans l'accès aux données. Je ne comprends pas que l'on puisse lire le champ texte sur sa longueur total alors qu'une chaîne plus courte a été écrite. Quelle que soit le type de codage de la chaîne de caractère (en C avec un zéro terminal, ou en Pascal - Généatique est très probablement écrit en Delphi - un tableau de caractère dont le 1er élèment contient la longueur de la chaîne), quand on écrit une chaîne on écrit tout (le texte + la longueur ou le zéro terminal). On peut penser que c'est la fonction de lecture de la chaîne qui n'est pas compatible avec la fonction d'écriture ou bien les accès en écriture et en lecture ne se font pas avec des variables de même type. Oh! ça c'est très technique ......
Un développeur du CDIP pourra peut-être, un jour, prendre quelques instants pour expliquer......

Cordialement

Michel P.

 

[michel13]

Bonsoir à tous,

Rien à voir avec Windows, Michel P !
Lui au moins sait garder un fichier complet et le fait bien.
Mais Généatique, à qui on ne demande rien de plus en ce domaine que son "Historique des Actions de saisie", se mêle de conserver de simples traces de données sans aucun intérêt pour personne.
Il ne sait tout simplement pas gérer correctement un simple item et, à son niveau, c'est bien regrettable.
Bien sûr on peut ne pas trouver cela bizarre ! . . . mais parfaitement incongru.

 

[dfx]

bonjour,
je crois qu'on s'arrêter là sur le sujet, ça devient complexe et on risque de dire des bêtises.
Et on n'a toujours pas d'écho d'anomalie originelle, a savoir a-t-elle été reproduite ?

 

[michel13]

Bonjour à tous,

Oui, je crois que vous avez raison, dfx, il semble que cela devienne complexe et il serait regrettable d'en venir à dire des bêtises.
Bien que ce ne soit pas à nous de les expliquer on peut quand même être inquiet en trouvant toutes ces d'anomalies sur un logiciel comme GENEATIQUE 2009 :
- Le post "Classement des illustrations (03/09)" qui est un petit bug lamentable pour lequel le CDIP, après avoir donner la réponse théorique, n'a, semble-t-il, pas vérifié qu'elle ne s'applique malheureusement plus à la version 2009 !
- Le cas LOBENI, développé ici.
- Mon Avatar, décrit ici.
- Le cas du Dictionnaire des données qui récupère tout un tas de données qui ne le concernent pas et pour lesquelles il n'en peut mais (Bien sûr on peut dire qui peut le plus . . .).
Tout cela en une semaine et je laisse à d'autres le soin de pointer depuis son lancement.
Bien que son fonctionnement d'ensemble apparaisse comme satisfaisant il semblerait que cette version du logiciel ne soit pas complètement aboutie malgré le correctif 1.3.