Uns astuce de nettoyage de la base

[assyril]

Bonjour,

Un petit post pour vous signaler une astuce que Nicole m'a suggéré par mail (suite à un echange long pour essayer de résoudre un problème).
En resumé j'avais des "descriptifs de source" qui réapparaissait à chaque mise à jour des tables de duplication sans être présent dans le dictionnaire; en ayant effacé le répertoire undobdd ... en ayant essayé toutes les astuces que l'on peut trouver sur le forum.
Cela pourrait peut être rejoindre le problème d'un post récent sur le nombre de témoin.
Généatique semble enregistrer des informations dans des "zone officieuse de la base de donnée"

Donc voici l'astuce :

Ce que je vous propose est de réaliser sur le vrais fichier, une extraction complète, mais avant réalisez une sauvegarde
Puis cliquez sur le menu Utilitaires puis effacer les tables de duplications

Puis l'extraction : Menu Utilitaires puis extraction en créant un nouveau fichier

Puis ouvrez le nouveau fichier
Puis cliquez sur le menu Utilitaires puis mettre à jour les tables de duplications

Cette manipulation m'a permis d'effacer 4 descriptifs de source qui officiellement n'existait plus et de remettre la fréquence des illustrations à leur bonne valeurs. en effet j'avais certaines illustrations qui était affecté 3 fois à la même fiche de personne.

Après un parcourt rapide de la base de donnée (j'ai plus de 2000 personnes, et plein de notes), il me semble que je n'ai rien perdu.

Donc si cela peut aider quelqu'un à nettoyer sa base.

Cordialement

 

[Michel P.]

Bonsoir,

Cette façon de faire a déjà été décrite, en ajoutant une condition, pour se débarrasser des fiches "fantômes".
Certaines manipulations permettent de créer des fiches vides (sans nom ni prénom). Dans les versions antérieures, on ne pouvait pas faire apparaître ces fiches vides pour les supprimer, une solution consistait donc à faire une extraction.

Cordialement

Michel P.

 

[assyril]

Bonsoir,

Et bien pourquoi vous ne me l'avez pas signalé quand il y a plusieurs mois j'avais exposé ce problème.
Qui n'est pas un problème de fiches fantômes. mais un problème d'informations qui est attaché à rien, on n'a aucun moyen de retrouver où se trouve cette information

Cordialement

 

[Michel P.]

Bonsoir,

Votre problème, comme vous dites "Qui n'est pas un problème de fiches fantômes", ne m'a pas fait penser à cette solution.
Certains problèmes font imaginer rapidement des pistes de solutions et d'autres non, malheureusement.
Avec la mise en évidence de cette solution à votre problème, on pourra penser à cette solution si un problème analogue devait apparaître.

Cordialement

Michel P.

 

[assyril]

Bonjour,

Avec la mise en évidence de cette solution à votre problème, on pourra penser à cette solution si un problème analogue devait apparaître.

.
C'était le but de ce post. car le problème, informatiquement parlant, j'ai du mal à l'appréhender.
En y réflechissant, en faisant une extraction, je ne garde que le coeur de la base, c'est à dire les données; et tous le reste qui doit être des rouages sont perdu mais peuvent être reconstruit. Je suppose que le la fonction de restructuration agit sur ces rouages. Mais là elle n'avait aucun effet.

Cordialement

 

[Michel P.]

Bonjour,

..... car le problème, informatiquement parlant, j'ai du mal à l'appréhender.

Il est évident que, sur ça (comme sur d'autres points évidemment), le CDIP a un gros avantage sur nous en connaissant l'outil base de données utilisé.
Ce qui est manifeste est que la base de données est compliquée (comme toutes les BDD un peu évoluées). La base est dynamique, en ce sens que toutes les informations pouvant être contenues dans une fiche ne sont pas créées à la création d'une fiche; cette technique permet de gagner beaucoup de place même si c'est plus coûteux en terme de gestion (ce qui est transparent pour nous à l'utilisation). Une fiche a une structure de base (des éléments indispensables tels que nom, prénoms et d'autres) et des éléments facultatifs qui ne seront créés dans la base qu'au moment du besoin.
C'est ainsi qu'on arrive au fonctionnement "trois états" des booléens. Tant que la donnée n'a pas été saisie, elle n'est pas créée dans la base (ainsi elle n'occupe pas de place). Cet état correspond à la condition "vide". Dès que la donnée est créée la condition devient "non vide" que la case soit cochée ou non cochée.

Cordialement

Michel P.

 

[predigny]

...Et bien pourquoi vous ne me l'avez pas signalé quand il y a plusieurs mois j'avais exposé ce problème.
....

A mon avis, c'était pour vous ennuyer un maximum : "Ah ah ! Je sais ce qu'il faut faire mais je ne vais pas le lui dire" :evil:

 

[michel13]

Bonjour à tous,

On en revient à la gestion des variable booléenne soulevée dans "Un enfant jumeau de trop !".
En fait il n'y a pas de booléen à trois états mais deux variables en série, celle de la fiche et celle de la base.
La première est non cochée ou cochée.
Pour la seconde c'est plus compliqué. Si la première n'a jamais été cochée la seconde n'existe pas. Si la première est cochée ou a été cochée puis décochée la seconde existe (elle est crée à la première coche de la variable de la fiche) et son existence, quelque soit l'état de la variable de la fiche, est définitivement interprété par la base comme "cochée". Il est, à priori, incompréhensible que la base ne sache pas détruire cette variable lorsque la coche disparait de la fiche et qu'il faille une action manuelle, indépendante de la variable de la fiche, pour la supprimer.
C'est ce que je qualifie de gestion rocambolesque des variables booléennes en espérant son amélioration dans une prochaine mise à jour.

Très cordialement
Michel

 

[michel13]

Bonjour à tous,

En complément à mon précédent message et pour tenir compte de la remarque pertinente de Michel P sur l'importance de la place mémoire occupée, j'ajoute que la destruction d'une variable inutile va dans le même sens que sa création seulement au moment de son utilisation.
Pourquoi donc dans cet environnement la valeur de la variable de la base ne suit-elle pas celle de la variable de la fiche avec une existence liée à la présence de la coche dans celle-ci ?

Très cordialement,
Michel

 

[verhaegenpatrice]

Bonjour,
Les choses ne sont peut être pas aussi simple que l'on pourrait le penser, à savoir que supprimer en mémoire la variable de la fiche conduirait peut être à supprimer cette variable pour toutes les fiches...
A suivre...
Cordialement

 

[michel13]

Bonjour à tous,

Cela serait encore plus étonnant, verhaegenpatrice, puisque seule la variable des fiches est commune à toutes les fiches. La variable de la base relative à une fiche n'appartient qu'à celle-ci et n'est crée dans la base pour cette fiche que si celle-ci est cochée une première fois.
Elle peut d'ailleurs être détruite pour une fiche dans la base selon un procédé décrit par Michel P dans le post "Un jumeau de trop !" sans affecter dans la base la variable des autres fiches. Ce n'est que l'automatisation de ce procédé qui serait souhaitable.

Très cordialement,
Michel

 

[assyril]

Bonsoir,

Je rajouterais une alerte sur ce post, car je m'en suis rendu compte aujourd'hui.
Lors de l'extraction, j'avais perdu les notices récemment créés. J'ai pu les récupérés facilement de la copie que j'avais fait avant l'extraction.
Donc à savoir.
J'ai pensais à vérifier car il y a eu un post sur les notices. Il y a peut-être d'autre chose de perdus! à voir avec le temps.
Donc je rejoint la suggestion de Michel13, il faudrait revoir la procédure de restructuration de la base, pour qu'elle nettoye mieux la BDD.

Cordialement

 

[michel13]

Bonsoir à tous,

En effet un fonctionnement logique et simple des variables fiche et base dans le genre :
- Fiche non cochée pas de variable Base.
- Fiche cochée création d'une variable Base.
- Fiche décochée suppression de la variable Base.
permettrait une meilleur gestion de la base et éviterait des erreurs tout en allant dans le sens de la remarque de Michel P concernant la minimisation de l'occupation de l'espace mémoire.
Elle éviterait aussi la création d'astuces de nettoyage de la base qui peuvent générer des erreurs ou des pertes de données involontaires comme en a subit Assyril.

Très cordialement,
Michel