Champs personnels boléens

[phicome]

Re,

J'ai créé un champ personnel "Jumeau", type boléen.
Pour tester, j'ai coché cette case sur un individu quelconque. Puis j'ai décoché la dite case.
Malgré cela G2010 considère que l'individu est bien un jumeau, case décochée (recherche par critères).
Ni effacement des tables, ni restructuration n'a changé quoi que ce soit.
Pour remédier au problème, il faut supprimer la fiche, et la recréer.
Bonjour le patacaisse en cas de clic intempestif, si tous les champs personnels se comportent ainsi.

 

[predigny]

C'est un peu étonnant ! J'ai fait la manip et ça marche tout à fait bien. Il y a cependant une nuance : quand la case Jumeaux a été cochée, la valeur de la variable booléen est O (Oui) et si on la décoche , elle devient N (Non), alors que les cases que l'on n'a pas touchées n'affichent ni Oui ni Non car la rubrique Jumeau n'a pas été créée. Dans les recherches il suffit de mettre la condition = O pour avoir la liste des jumeaux.
Si la rubrique Jumeaux = N vous gène, il suffit de supprimer la rubrique dans la Fiche détaillée.

 

[michel13]

Bonsoir,

C'est le problème des variable booléennes à trois états propres à Généatique dont on parle depuis l'origine !
La base sait incrémenter mais pas décrémenter sans aide !!
Tous les champs de ce type réagissent ainsi.
- Coché = O c'est à dire créé = 1 pour la base.
- Décoché = N c'est toujours existant donc toujours = 1 pour la base.
- Détruit = non créé ou inexistant = 0 pour la base.
D'où les trois états !!!
En fait le troisième état, décoché, est un leurre.
Il ne faut jamais décocher mais détruire dans la fiche détaillée car sur la fiche il n'y a aucune différence visuelle entre la case vide et la case "détruite".

 

[dfx]

bonsoir

C'est vrai ce booléen a 3 états (!?), indéterminé (NULL, cad jamais manipulé, coché ou décoché), coché (VRAI), décoché (FAUX)
Informatiquement un booléen, à sa création, doit avoir une valeur par défaut pour éviter cet indéterminisme, Généatique ne me permet pas

Donc il y a un incertitude sur l'état FAUX (décoché) et l'état NULL (jamais coché/décoché),
la seule certitude est l'état VRAI (coché), il faut faire avec.

On doit donc se posé qu'une seule question le booléen est-il VRAI (O,o,coché,...) ou pas :
cela se traduit dans les requêtes par :
<booléen> égal à O (cad coché)
ou
<booléen> différent de O (cad non coché ou jamais initialisé)

C'est d"ailleurs l'usage en programmation informatique on teste le VRAI ou le NON-VRAI

La base sait incrémenter mais pas décrémenter sans aide !!

la notion d'incrémentation se pose pas ici

 

[phicome]

Merci pour vos lumières.

Un boléen à trois états n'a rien de boléen.

Quant à Vrai-Faux, encore faut-il pouvoir le déterminer. G2010 gère le boléen en Vide-Non vide. Et "Vide" n'est pas forcément vide...

 

[michel13]

Bonjour,

O que si elle se pose et c'est bien là tout le problème !
Avec ce genre de champs les statistiques racontent tout et n'importe quoi si l'on n'y prend pas garde.
Dans les statistiques, gérées par la base :
- si on coche on a +1 donné par la base. Elle incrémente.
- Normalement si on décoche on devrait avoir -1 donné par la base. Elle devrait décrémenter.
Mais elle ne sait pas le faire sans aide. Pour elle l'état coché est definitif que la coche soit présente ou absente. Il faut aller détruire dans la fiche détaillée la création de la valeur pour qu'elle consente à décrémenter !!
Et c'est cela qu'il faut faire plutôt que de décocher. Sinon on peut avoir 13 jumeaux sans avoir autre chose que des naissances doubles (c'est comme cela que j'ai découvert cette histoire) et c'est n'importe quoi !
C'est un point qui malheureusement n'est pas pris au sérieux par le CDIP.
Car, et je rejoins là les puristes, une variable booléenne standard ne doit avoir que deux états "oui" et "non", "vrai" et "non vrai" ou "faux", c'est à dire pour ce qui nous intéresse "coché" et "décoché". Ou alors une procédure doit être décrite pour annuler l'effet de la coche et ce n'est plus une variable Booléenne simple.
Page 67 du guide on parle bien de champ de type Booléen que l'on coche.
Nulle part il est indiqué que ce geste est définitif et que son contraire n'a aucun sens pour Généatique.
D'où, périodiquement, ces discutions sans fin qui n'aboutissent malheureusement à rien.

 

[predigny]

Ce n'est pas spécifique aux booléens : Si l'on créé une donnée de type texte, par exemple "Lien du sang", cette donnée peut-être mise sur l'écran de saisie de la fiche simple et y est toujours visible, mais tant que l'on a pas rentré de texte, il n'y a pas de rubrique Lien du sang visible sur la fiche détaillée. Mais si on utilise cette donnée, la rubrique apparait dans la fiche détaillée avec son contenu (texte), et même si on supprime ensuite tout le texte de cette donnée, la rubrique apparait toujours dans la fiche détaillée, mais avec un contenu vide. C'est exactement comme pour la variable booléen, qui n'a bien que deux état, mais n'existe que si une rubrique est créée pour une fiche donnée (ce qui peut apparaître comme un état supplémentaire de la variable). L'existence de la rubrique est indépendante de son contenu mais est liée sa première utilisation pour une fiche donnée.
Du moins c'est comme cela que je vois ça.

 

[dfx]

- si on coche on a +1 donné par la base. Elle incrémente.
- Normalement si on décoche on devrait avoir -1 donné par la base. Elle devrait décrémenter.

Mais incrémentation de quoi ???

Une petite explication ... c'était mon métier :
quand vous créez une fiche tous les champs sont créés dans le corps de l'enregistrement, 2 cas :
- soit directement avec une longueur de caractères réservée pour les champs obligatoires et d'autres aussi comme les dates, les boléens
- soit par une indirection (c'est une adresse qui pointera sur la donnée lorsqu'elle sera créée), généralement pour les champs non obligatoires en mode texte de longueur variable
Je fais court car ce n'est pas aussi simple que cela.

Les champs qui ne sont pas initialisés lors de la création de l'enregistrement, sont mis à NULL
Pour les booléens si on ne les initialisent pas (ce qui est une erreur) il y aura donc NULL, normalement ce champ devrait prendre la valeur par défaut, VRAI ou FAUX (avec représentation qui diffère en fonction des bases de données)

Alors pourquoi le CDIP n'a pas choisi une valeur par défaut (VRAI ou FAUX) à la création de la fiche ? J'ai une explication;
- le fait que l'on peut modifier à la volée la structure de l'enregistrement et donc créer par exemple un champ boléen, il faudrait lors l'ajout de ce champ, balayer toute la base pour initialiser ce champ à la valeur par défaut. Peut-être un peu lourd si la base est conséquente. Ce choix n'a pas été fait.

Dans une gestion de base de données la modification de la structure de l'enregistrement n'est pas une opération anodine, elle implique toujours une réorganisation de la base.

Donc nous devons faire avec :

On doit donc se posé qu'une seule question le booléen est-il VRAI (O,o,coché,...) ou pas :
cela se traduit dans les requêtes par :
<booléen> égal à O (cad coché)
ou
<booléen> différent de O (cad non coché ou jamais initialisé)

 

[predigny]

Votre explication sur les enregistrements dynamiques me convient très bien et correspond à ce que l'on voit : la création du champ se traduit par l'apparition de la rubrique correspondante dans la fiche détaillée et c'est indépendant de son contenu.

 

[michel13]

Bonjour,

Certains ont dit : Il n'y a pire sourd que celui qui ne veut entendre !
J'ai bien commencé par parler des Statistiques.
C'est là que tout se passe et qu'avec des champs ingérables on obtient des résultats ridicules.
C'est évidement là que l'incrémentation se fait et que la décrémentation ne se fait pas.
Tout le reste n'a aucun intérêt car on peut trouver des explications à tout même et surtout à ce qui n'en a pas !
Le seul problème qu'il y a c'est qu'il n'existe aucune différence visuelle entre une case non cochée qui vaut 0 et une case décochée qui vaut toujours 1 !!! Dans les statistiques bien sûr.
Et cela quelques puissent être les développements mathématiques ou philosophiques que l'on puisse faire pour l'expliquer.
Quand il y en a une cinquantaine réparties sur une généalogie c'est très pratique de les rechercher pour détruire les valeurs et les remettre à zéro. Il y a des listes et des conditions pour cela et puis ça occupe !
Ce que je ne comprends pas c'est pourquoi le CDIP s'entête à ne pas rendre la coche inaliénable tant que l'on ne procède pas à la remise à zéro du champs par la destruction de la valeur dans la fiche détaillée donnant ainsi à la coche une véritable valeur de 1. Ce serait à la fois simple et surtout logique : pas de coche 0, une coche 1. De plus la procédure de remise à zéro existe. Il suffit de la rendre obligatoire pour que les statistiques de Généatique ressemblent à quelque chose.
Cela ne doit pas changer la gestion de la base et supprimerait l'état ridicule de la "coche décochée" qui vaut toujours 1 et qui surtout ne se voit pas !!!
Cela permettrait d'avoir une véritable variable Booléenne en dehors de toutes polémiques.
Mais pourquoi faire simple quand on peut faire compliqué ? Je vous le demande !
Et puis si cela amuse les utilisateurs, lorsqu'ils s'aperçoivent que leurs statistiques sont erronées, d'ouvrir un nouveau post sur le sujet alors tout va bien.

 

[predigny]

...
Le seul problème qu'il y a c'est qu'il n'existe aucune différence visuelle entre une case non cochée qui vaut 0 et une case décochée qui vaut toujours 1 !!! Dans les statistiques bien sûr.
...

C'est quoi une case décochée qui vaut toujours 1 ?
Je n'utilise pas beaucoup les statistiques, mais si une "case booléenne" décochée est considérée comme avoir la valeur "vraie", c'est juste une erreur du programme. Pas la peine de s'énerver :mrgreen: dites nous seulement comment on voit cette erreur.

 

[phicome]

C'est quoi une case décochée qui vaut toujours 1 ?
Je n'utilise pas beaucoup les statistiques, mais si une "case booléenne" décochée est considérée comme avoir la valeur "vraie", c'est juste une erreur du programme. Pas la peine de s'énerver :mrgreen: dites nous seulement comment on voit cette erreur.

...1er post...

 

[predigny]

...1er post...

Oui, mais au 2eme post, j'ai dit avoir fait la manip et que ça marchait bien, alors soit je n'ai pas fait la même "Recherche par critère" que vous, soit ... il y a d'autres précisions à donner.

 

[dfx]

C'est évidement là que l'incrémentation se fait et que la décrémentation ne se fait pas.

La notion d'incrément n'a pas d'existence ici

Le seul problème qu'il y a c'est qu'il n'existe aucune différence visuelle entre une case non cochée qui vaut 0 et une case décochée qui vaut toujours 1 !!!

NON, une case non cochée vaut NULL, case décochée est à FAUX (je dit FAUX ou FALSE car la valeur derrière ce mot diffère suivant les languages informatique) même si visuellement c'est invisible

remise à zéro du champs par la destruction de la valeur dans la fiche détaillée donnant ainsi à la coche une véritable valeur de 1

Confusion entre contenant et contenu

Et puis si cela amuse les utilisateurs, lorsqu'ils s'aperçoivent que leurs statistiques sont erronées

Il faut exprimer une bonne requête pour avoir une bonne réponse

Il n'y a pire sourd que celui qui ne veut entendre !

avez-vous dit ....
Je termine là la discussion

 

[phicome]

A tous !

Doivent se marrer, au CDIP, à lire les enguelades des uns et des autres !
Se marrent, modèrent ce forum, mais n'interviennent pas souvent !
Modèrent ce forum ?

 

[predigny]

On s'engueule, mais on s'aime bien, c'est l'essentiel ! :lol:
Quant au CDIP, je crois qu'ils prennent quelques notes au passage.

 

[phicome]

Quant au CDIP, je crois qu'ils prennent quelques notes au passage.

Devrait y avoir une case à cocher "Vu par le CDIP" :wink:

 

[michel13]

Bonjour,

Encore heureux que l'on s'aime bien sinon aucune discussion possible !
Quelqu'un a-t-il lu le premier message de phicome dans ce post ?
A sa relecture il me semble que l'on comprend mieux ce que j'ai du mal à exprimer.
Le CDIP doit d'autant plus se marrer que cette discussion à épisodes dure depuis l'origine de Généatique. Qu'ils sont au courant et que la réalité des statistiques de leur programme leur importe peu.
Et pourtant une case décochée vaut toujours "1" ou "oui" ou tout ce que l'on veut sauf "0" ou "Non" comme s'en ait aperçu phicome qui a du aller détruire la variable dans la fiche détaillée pour corrigé son problème.
"Bonjour le patacaisse en cas de clic intempestif, si tous les champs personnels se comportent ainsi" a-t-il conclu avec juste raison.