Enfant jumeau de trop !

[michel13]

Bonjour à tous,

J'ai réussi à avoir 7 jumeaux sous Généatique 2009 ! sans avoir de triplés et autres quintuplés.
J'ai créé un type Enfant jumeau Booléen (O/N) que j'ai coché 7 fois.
La dernière fois était une erreur et je l'ai décoché.
Depuis lorsque je fais "Information sur le dossier Généalogique" puis "Nombre de champs simples" j'ai 7 jumeaux.
J'ai recoché et redécoché la case, restructuré la généalogie, rien n'y fait.
En désespoir de cause j'ai coché une huitième fois ce type et j'ai eu huit jumeaux. J'ai décroché les deux dernière coches et j'ai toujours eu huit jumeaux. Même aprés restructuration.
La base d'information incrémente ce type mais ne le décrémente pas.
J'ai restauré ma généalogie à l'étape "7 jumeaux" dont 6 cochés et je demande de l'aide pour supprimer le jumeau de trop !

Bien amicalement,
Michel

 

[michel13]

Bonjour à tous,
En complément à mon précédent message j'ajoute que si je supprime le type "Enfant jumeau" le nombre de jumeaux dans "Information sur le dossier généalogique" ,"Nombre de champs simples" reste inchangé.
Lorsque je rétablis le type, je retrouve les cases cochées comme avant la suppression. Il y a toujours 6 cases cochées et 7 jumeaux répertoriés.
Je n'ai pas verifié si ce problème existe pour d'autres types Booléen.

Bien cordialement,
Michel.

 

[Michel P.]

Bonsoir,

L'utilisation de ces informations est différente selon les informations.
Dans le cas de cette information "Enfant jumeau", le nombre représente le nombre de fiches sur lesquelles cette case apparaît (cochée ou non).

Dans le cas d'une case décochée on peut la faire disparaître et ainsi décrémenter d'un le nombre en passant par l'onglet "Compléments" puis "Supprimer des rubriques".

Je ne me suis pas posé la question de savoir à quoi ça sert....

Cordialement

Michel P.

 

[michel13]

Bonsoir Michel,

Contrairement à ce que vous écrivez, et heureusement, le nombre indiqué ne correspond pas au nombre de cases cochées ou non qui apparaissent mais, tant que l'on incrémente, au nombre de case cochées. Cela parait assez logique avec une rubrique de type Booléen.
Ce qui l'est moins c'est que le système ne sache pas se décrémenter lorsque l'on décoche les cases.
En relisant votre réponse j'ai l'impression que vous n'avez pas bien compris ce que j'ai essayé d'exprimer dans mes précédents messages.
Peut être me suis-je mal exprimé mais une base de données qui est capable de s'incrémenter en refusant l'opération inverse ne ressemble à rien de valable et c'est ce qui se passe dans ce cas là.
Votre procédure de passer par "Complément" puis "Supprimer des rubriques" ne s'applique pas à ce cas puisque la case est déjà décochée, qu'il ne s'agit pas d'une rubrique ajoutée à cette fiche et qu'il n'y a rien à supprimer. En d'autres termes la rubrique existe sur toutes les fiches et n'est cochée que sur celles correspondant à des jumeaux. Si on coche on incrémente bien mais si on décoche rien ne se passe.

Bien cordialement,
Michel

 

[Michel P.]

Re,

Contrairement à ce que vous écrivez, et heureusement, le nombre indiqué ne correspond pas au nombre de cases cochées ou non qui apparaissent mais, tant que l'on incrémente, au nombre de case cochées. Cela parait assez logique avec une rubrique de type Booléen.
Ce qui l'est moins c'est que le système ne sache pas se décrémenter lorsque l'on décoche les cases.

La dernière phrase montre bien que nous constatons la même chose. Et je confirme ce que j'ai écrit: il s'agit bien du nombre de cases cochées ou non. Est-ce normal ou pas, je n'ai pas la réponse mais c'est ce que l'on peut constater pour l'instant.

Si on coche on incrémente bien mais si on décoche rien ne se passe.

Il ya eu de nombreux débats sur la base de données de Généatique et sur la bizarrerie des booléens à trois états (cherchez "confidentiel").
Quand on coche une case d'un champ qui n'a pas encore été utilisé, il y a deux opérations réalisées:
- création du champ dans la base,
- mise à 1 du champ.
En effet, avant de cocher la case, le champ n'a pas été créé dans la base.

Quand on décoche le champ, on ne réalise qu'une opération: la mise à zéro. Le champ ne disparaît pas de la base (sauf à supprimer la rubrique).

Ainsi on peut dire qu'il y a trois états pour un booléen:
- coché,
- décoché (après avoir été coché),
- pas encore coché.

Cela explique qu'il faut prendre des précautions quand on fait une condition sur un booléen. Il est bien préférable de faire le test sur la valeur "vrai" (on dit aussi "oui" ou "1").

Cordialement

Michel P.

 

[michel13]

Bonjour Michel,

Vous avez écrit :

Quand on décoche le champ, on ne réalise qu'une opération : la mise à zéro. Le champ ne disparaît pas de la base (sauf à supprimer la rubrique).

Et c'est là que nos observations divergent. En effet le champ est bien remis à zéro sur la fiche et reste inchangé dans la base (ce qui est un non sens) mais même en supprimant la rubrique, les champs de la base restent inchangés, toujours 7 jumeaux, bien qu'il n'y ait plus de rubrique et que la généalogie aie été restructurée ce qui tout à fait anormal : la suppression de la rubrique ne provoque pas sa remise à zéro dans la base.

De plus en rétablissant la rubrique on retrouve les cases précédemment cochées (6 cases, la septième ayant été décochée) et toujours 7 jumeaux dans la base. Le système garde en mémoire le dernier état croissant envers et contre tout.
Donc même en supprimant la rubrique je ne peux pas faire disparaître l'inscription ridicule "Enfants jumeaux 7 " dans les "Informations sur le dossier généalogique", "Nombre de champs simples".

Dans un système normalement conçu lorsque l'on coche une case d'une variable booléenne on l'incrémente d'une unité et lorsque l'on décoche cette case on la décrémente d'une unité.
Les informations recueillies à son sujet par une base centrale doivent suivre les mêmes changements d'états.
En supprimant cette variable on doit par la même occasion supprimer ses informations de la base.
Tout autre fonctionnement est aberrant et relève plus du bug informatique que d'un hypothétique booléen à "trois états" qui serait spécial au CDIP et doit faire se retourner monsieur Georges BOOLE dans sa tombe.
Il n'y a pas de bizarrerie qui tienne et je me permets de rappeler ici la définition des variables booléennes :
Variables Booléennes : qui ne peut prendre que deux valeurs distinctes (Petit Robert).

En suivant les instructions du logiciel j'ai cru créer une rubrique Enfant jumeaux du type "Booléen : Vrai/Faux" comme précisé dans "Structure du fichier". Coché = Vrai, Décoché = Faux. Toute base de données traitant cette information doit pouvoir suivre naturellement l'incrémentation et la décrémentation.
Or si cette rubrique peut avoir plus de deux états ce n'est pas un booléen et, je regrette de le dire, les instructions sont erronées et trompeuses. Dans ce cas la base peut ne pas pouvoir suivre les incrémentations et décrémentations puisque l'on sort du domaine binaire qui est le propre des variables booléennes pour entrer dans un domaine parfaitement erratique qui ne reflète plus la réalité.
Je suis déçu que Généatique laisse croire qu'il peut avoir un tel fonctionnement.

Très cordialement,
Michel

 

[dfx]

Bonsoir,
si je peux mettre mon grain sel, les constations de [michel13] sur l'utilisation des champ booléens m'ont interpellé. Il est vrai que les champs booléens à 3 états cela semble curieux mais ils sont néanmoins bien pratiques pour répondre au question "oui/non/je ne sais pas" ... et ce "je ne sais pas" nous ne rencontrons souvent dans notre activité.
Il suffirait de ne plus les nommer booléens et ce serait plus simple.
Reliser les réponses de [Michel P.] elles parfaites.

En fait il faut bien comprendre le fonctionnement ce faux booléen, pour poser les bonnes requetes (vide, non vide( O, N)). Pour votre cas si le "Nombre de champs simples" ne décrémente pas c'est parfaitement normal puisque ceci indique la présence de ce champ (ou rubrique) sans tenir compte de sa valeur (O ou N). Si vous voulez comptez vos jumeaux passez par les requetes de recherche de fiche.

C'est vrai néanmoins qu'il est quelques fois génant de ne pas savoir si une case non cochée représente un état vide (donc sans donnée) ou N (faux, 0).
Je vous assure il n'y a aucun bug dans le fonctionnement de ce type de donnée juste une maladresse dans l'appellation de ce type de donnée

 

[michel13]

Bonjour à tous,

Bien sûr DFX que vous pouvez mettre votre grain de sel dans la discussion que j'avais avec Michel P. Cela est même recommandé.
En réponse pour les champs à trois états ou plus il vaut mieux utiliser la "Liste de choix". Donc pour ceux à deux états on peut utiliser un champs dit booléen.
En fait, dans mon cas, la rubrique "Enfant jumeau" crée et implantée dans la fiche est bien booléenne avec deux états : coché ou non coché.
Pour une fiche donnée elle est d'abord non cochée.
Si on la coche elle devient cochée. Mais, ainsi que l'a bien décrit Michel P, la base centrale ne suit pas la même procédure.
Lorsque la case est cochée la base se crée pour cette fiche une rubrique particulière "Enfant jumeau". Elle s'incrémente sur la création de cette rubrique. Lorsque l'on décoche la case de la rubrique de la fiche rien ne se passe dans la base qui ne sait pas, alors, détruire la rubrique crée précédemment.
Pour décrémenter la base il faut une action manuelle complémentaire, à exécuter non pas dans la fiche mais dans les compléments, pour supprimer ce qui est nommé "rubrique" et qui est en fait la rubrique crée dans la base à l'incrémentation. La base se décrémente alors d'une unité.
Il y a en fait une "rubrique" Enfant jumeau générale au niveau des fiches et des "rubriques" spécifiques à chaque fiche crées à l'occasion dans la base ce qui n'est pas facile à exprimer.
Si on décoche plusieurs fiches sans exécuter la manip dans les compléments on risque de ne plus savoir, d'une façon simple, dans quelles fiches il faut agir.

u]Il apparaît, après expérimentation, que pour supprimer un enfant jumeau dans ce système, il ne faut pas décocher la case de la fiche mais il faut aller directement dans "Compléments", "Supprimer une rubrique" et supprimer "Enfant jumeau".[/u] A ce moment la coche disparaît sur la fiche et la base se décrémente d'une unité en une seule opération.

Ce processus s'applique sans doute à toutes les rubriques crées avec une variable dite "booléenne".
Je trouve ce fonctionnement absolument hors norme car l'incrémentation et la décrémentation ne dépendent pas de la même entrée ce qui est parfaitement illogique et peut être source d'erreur.
Le problème n'est plus de savoir si les variables sont ou non booléennes mais de quelle logique dépend le fonctionnement du système.

Pour moi le problème est résolu et je remercie tous ceux qui m'ont aidé, mais je reste quand même un peu déçu par un tel processus.
J'espère qu'une prochaine mise à jour corrigera cette rocambolesque gestion des variables booléennes.
Très cordialement,
Michel