Auteur Sujet: Recherche cle_fixe non renseignée  (Lu 6811 fois)

plus minus reset

0 Membres et 1 Invité sur ce sujet

Hors ligne Horemans

  • AncestroSenior
  • *****
  • Messages: 1 775
    • http://perso.wanadoo.fr/philippe.horemans
Recherche cle_fixe non renseignée
« le: 27 Octobre 2005 à 16:25:44 »
Toutes les clés liens externes ne sont pas renseignées dans la table INDIVIDU (champ CLE_FIXE) et je voudrais forcer le champ à la valeur du nip.



Quand j'analyse la table avec la condition suivante, je n'ai aucune réponse à ma requête :

WHERE

  (CLE_IMPORTATION <> INDIVIDU.CLE_FIXE)

alors que si je mets = au lieu de différent, j'ai des résultats.



Même chose dans le requêteur et le BOA, c'est donc bois qui moi  :wink:  mais où  :?:  :evil:
Plus çà va, plus je me régale...  Et avec  Quisontils, la gestion des actes, c'est facile !   Philippe
 

Hors ligne DDdeBerdeux

Recherche cle_fixe non renseignée
« Réponse #1 le: 27 Octobre 2005 à 17:04:44 »
Citation de: "Horemans"
c'est donc bois qui moi
Ptêt ben :lol: Tu n'aurai pas faît la maj avant?

Chez moiselect CLE_FICHE

from INDIVIDU

where  (CLE_IMPORTATION <> INDIVIDU.CLE_FIXE)
fonctionne.

Je pense que pour la maj je ferai plutotUPDATE INDIVIDU SET CLE_FIXE=CLE_FICHE

WHERE CLE_FIXE IS NULL
Le NIP, c'est la CLE_FICHE. Si j'ai bien compris CLE_IMPORTATION doit être le code que l'individu portait dans le gedcom lors de son importation, elle peut donc être différente de la CLE_FICHE. Elle est souvent égale parce que on a réimporté son propre dossier.

Pour vérifier s'il n'y a pas de doublons de CLE_FIXE j'avais fait une requête qui doit trainer sur le forum.

A+

André
Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée. (Loi des Mises à Jour)
 

Hors ligne DDdeBerdeux

Recherche cle_fixe non renseignée
« Réponse #2 le: 27 Octobre 2005 à 17:23:39 »
C'était celle-làselect i.CLE_FICHE , i.CLE_FIXE , i.NOM , i.PRENOM

from INDIVIDU i

where i.KLE_DOSSIER=1

and i.CLE_FIXE is not null

and (select count(i2.CLE_FIXE)

from INDIVIDU i2

where i2.CLE_FIXE=i.CLE_FIXE)>1

order by i.CLE_FIXE , i.NOM , i.PRENOM



Je viens d'en trouver 11 dans mon dossier, et j'en ignore la raison. Pas d'importation récente? Encore une anomalie d'Ancestrologie? Une petite "coucouille" à PCM qui aurait inversé CLE_FIXE et CLE_FICHE dans son code?

Je serais curieux de savoir si je suis le seul à avoir ce problème.

A+

André

PS: non pas de coucouille à PCM, mais la conséquence logique d'une importation, même ancienne. Avant exportation la CLE_FIXE et la CLE_FICHE étaient par exemple de 2000. Après une importation les CLE_FIXE ne bougent pas mais les CLE_FICHE sont renumérotées à partir de 1. Donc si mon fichier comportait moins de 2000 individus, lorsque je crée des fiches maintenant je peux réattribuer le code 2000 à CLE_FCHE et à CLEF_FIXE, créant un doublon de CLE_FIXE. Donc tous les jours on peut créer des doublons :mrgreen:
Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée. (Loi des Mises à Jour)
 

Hors ligne Horemans

  • AncestroSenior
  • *****
  • Messages: 1 775
    • http://perso.wanadoo.fr/philippe.horemans
Recherche cle_fixe non renseignée
« Réponse #3 le: 27 Octobre 2005 à 19:45:54 »
Chez moiselect CLE_FICHE

from INDIVIDU

where  (CLE_IMPORTATION <> INDIVIDU.CLE_FIXE)
ne renvoie aucun résultat alors que j'ai bien des CLE_FIXE non renseignées.(edit)

C'est effectivement CLE_FICHE qui est le nip, et je vais utiliser l'update que tu donnes pour modifier ma table, mais avant je veux comprendre pourquoi le select qui précède ne donne rien.

J'ai a nouveau vérifié si j'avais des doublons de CLE_FIXE, je n'en ai jamais eu, mais aussi, je n'ai jamais utilisé mes sauvegardes Gedcom, ce qui veut dire que ton explication tient la route.



Je recopie ce qui suit dans le forum Suggestions



Pour éviter les doublons, il faudrait qu'après un réimport gedcom, lors de la création d'un nouvel individu,la clé lien externe (CLE_FIXE) soit égale au NIP suivant + une constante qui serait égale à la plus grande clé lien précédemment affectée   et utilisée dans Quisontils. Tout doublon serait alors impossible.

Quisontils est maintenant capable de donner cette information dans préférences générales/Liens externes/Régénérer les listes des clés de tous les albums. Cette constante pourrait être introduite manuellement dans les préférences d'Ancestrologie, aussitot l'import gedcom. Elle reste à zéro tant qu'il n'y a pas d'import gedcom de restauration.
Plus çà va, plus je me régale...  Et avec  Quisontils, la gestion des actes, c'est facile !   Philippe
 

Hors ligne Horemans

  • AncestroSenior
  • *****
  • Messages: 1 775
    • http://perso.wanadoo.fr/philippe.horemans
Recherche cle_fixe non renseignée
« Réponse #4 le: 27 Octobre 2005 à 20:16:40 »
A noter que si, dans Ancestrologie, je balaye la base avec les flèches en bas à droite de l'écran (fonction fiche suivante), le champ CLE_FIXE de  la table INDIVIDU se met à jour automatiquement sans avoir à modifier quoi que ce soit.

Si j'étais courageux, il me suffirait de répéter l'opération 5600 fois pour que toute la table INDIVIDU soit corrigée. Heureusement, il y a le SQL  :!:
Plus çà va, plus je me régale...  Et avec  Quisontils, la gestion des actes, c'est facile !   Philippe
 

Hors ligne Ransac

  • Modérateur Global
  • AncestroGrandMaitre
  • *****
  • Messages: 3 015
  • Remercié: 1 fois
    • bases des villes
  • Programme: 2015-1996.3
  • Base: 5.131
  • Système: Windows vista, Windows 7, Windows 10
Recherche cle_fixe non renseignée
« Réponse #5 le: 27 Octobre 2005 à 20:44:34 »
Citation de: "DDdeberdeux"
Je viens d'en trouver 11 dans mon dossier, et j'en ignore la raison. Pas d'importation récente? Encore une anomalie d'Ancestrologie? Une petite "coucouille" à PCM qui aurait inversé CLE_FIXE et CLE_FICHE dans son code?

Je serais curieux de savoir si je suis le seul à avoir ce problème.

j'en ai une en double, pourtant, moi non plus je n'ai rien fait !  :shock:

Il doit bien y avoir une petite "coucouille" quelque part !  :cry:
N'oubliez jamais que le mieux est l'ennemi du bien  et que la perfection n'est pas de ce monde !
Les définir est un défi, les réaliser est un leurre !    ... mais on aimerait tellement y croire!
 

Hors ligne Ransac

  • Modérateur Global
  • AncestroGrandMaitre
  • *****
  • Messages: 3 015
  • Remercié: 1 fois
    • bases des villes
  • Programme: 2015-1996.3
  • Base: 5.131
  • Système: Windows vista, Windows 7, Windows 10
Recherche cle_fixe non renseignée
« Réponse #6 le: 27 Octobre 2005 à 20:47:19 »
peux-tu faire une requête qui ne recherche pas les clés en double, mais les individus ayant une clé différent du NIP ?

merci d'avance !  :wink:
N'oubliez jamais que le mieux est l'ennemi du bien  et que la perfection n'est pas de ce monde !
Les définir est un défi, les réaliser est un leurre !    ... mais on aimerait tellement y croire!
 

Hors ligne Horemans

  • AncestroSenior
  • *****
  • Messages: 1 775
    • http://perso.wanadoo.fr/philippe.horemans
Recherche cle_fixe non renseignée
« Réponse #7 le: 27 Octobre 2005 à 20:51:22 »
C'est ce qui ne marche pas chez moi :

select *

from INDIVIDU

where  (CLE_FICHE <> CLE_FIXE)
Plus çà va, plus je me régale...  Et avec  Quisontils, la gestion des actes, c'est facile !   Philippe
 

Hors ligne Ransac

  • Modérateur Global
  • AncestroGrandMaitre
  • *****
  • Messages: 3 015
  • Remercié: 1 fois
    • bases des villes
  • Programme: 2015-1996.3
  • Base: 5.131
  • Système: Windows vista, Windows 7, Windows 10
Recherche cle_fixe non renseignée
« Réponse #8 le: 27 Octobre 2005 à 20:53:31 »
peut-être n'en as-tu pas de différent ?
N'oubliez jamais que le mieux est l'ennemi du bien  et que la perfection n'est pas de ce monde !
Les définir est un défi, les réaliser est un leurre !    ... mais on aimerait tellement y croire!
 

Hors ligne Horemans

  • AncestroSenior
  • *****
  • Messages: 1 775
    • http://perso.wanadoo.fr/philippe.horemans
Recherche cle_fixe non renseignée
« Réponse #9 le: 27 Octobre 2005 à 20:59:30 »
Si Si... des tas de non renseignés, bien plus que d'identiques. Quand je teste sur égalité, j'en ai un bon millier, ma base contient 5600 individus



On dirait que seules les fiches visitées et celles crées depuis la création de cette clé sont renseignées. Ce n'est pas anormal, mais même en testant la zone à NULL, je ne trouve pas
Plus çà va, plus je me régale...  Et avec  Quisontils, la gestion des actes, c'est facile !   Philippe
 

Hors ligne Gvx

  • AncestroJunior
  • ****
  • Messages: 361
Recherche cle_fixe non renseignée
« Réponse #10 le: 27 Octobre 2005 à 21:31:53 »
Citation de: "Horemans"
C'est ce qui ne marche pas chez moi :

select *

from INDIVIDU

where  (CLE_FICHE <> CLE_FIXE)


Je viens de tester cette requête et... elle fonctionne :D



Petite précision: j'ai pris une base vide (celle mise a jour par André), j'ai importé ma dernière sauvegarde gedcom de ma base de travail. j'ai donc des CLE_FICHE débutant à 1 et des CLE_FIXE à 68000.



Pour obtenir a la fois les CLE_FIXE différentes de CLE_FICHE et les CLE_FIXE a null vous pouvez utiliser la requête suivante: :wink:

select *

from INDIVIDU

where (CLE_FIXE IS NULL) OR  (CLE_FICHE <> CLE_FIXE)



Citation de: "Horemans"
On dirait que seules les fiches visitées et celles crées depuis la création de cette clé sont renseignées. Ce n'est pas anormal, mais même en testant la zone à NULL, je ne trouve pas


Effectivement la mise a jour de la CLE_FIXE ne se fait que lors de l'accès a la fiche (il n'y a pas eu de mise a jour de la base lors de l'introduction de la CLE_FIXE) :o

Hors ligne Horemans

  • AncestroSenior
  • *****
  • Messages: 1 775
    • http://perso.wanadoo.fr/philippe.horemans
Recherche cle_fixe non renseignée
« Réponse #11 le: 27 Octobre 2005 à 22:18:33 »
Citation de: "Horemans"
même en testant la zone à NULL, je ne trouve pas


Là, j'ai fait erreur. Dans ce cas je trouve mes petits.

Par contre çà ne marche toujours pas quand je conditionne seulement sur l'inégalité.

J'abandonne, je pers mon temps et celui des autres.

Je modifie ma base, ainsi j'aurai égalité des 2 champs sur toutes les lignes, ce qui est normal dans mon cas.

Merci
Plus çà va, plus je me régale...  Et avec  Quisontils, la gestion des actes, c'est facile !   Philippe
 

Hors ligne DDdeBerdeux

Recherche cle_fixe non renseignée
« Réponse #12 le: 27 Octobre 2005 à 22:19:29 »
Mes excuses mais j'ai répondu au message d'Horemans dans les suggestions avant de revoir ce fil. Je pense que le pb peut-être résolu par des triggers contrôlant la valeur de la cle_fixe lors de la création ou la modification. J'essaierai si j'en ai le temps...

La requête pour Ransac elle existe déjà là http://www.ancestrologie.org/forum/index.php?topic=4455.0

A+

André
Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée. (Loi des Mises à Jour)
 

Hors ligne DDdeBerdeux

Recherche cle_fixe non renseignée
« Réponse #13 le: 28 Octobre 2005 à 10:55:34 »
Cà y est c'est fait, j'ai mis sur le forum "Développement" sujet "Corrections et améliorations des procédures stockées", une requête modifiant 2 triggers. Avant enregistrement, il est vérifié que la nouvelle CLE_FIXE n'existe pas déjà, si elle existe on en cherche une libre à partir de 1.

Ceux qui ont IBOConsole peuvent l'exécuter pour mettre à jour la base (les triggers, pas les clés en double!), après la sauvegarde de rigueur. Ne le faîtes pas avec le BOA, çà plante même Ancestrologie!

Pour mettre à jour les données, si vous n'avez pas des dizaines de doublons, le plus simple est d'en faire la liste avec la requête vu hier, puis de les modifier par la fiche un à un. Vous pouvez mettre systématiquement 1 comme nouveau N°, le trigger le modifiera s'il existe déjà. D'ailleurs PCM avait déjà pensé à cette attribution de N° en double lors de la modification (une fenêtre à laquelle vous pouvez répondre oui, le signale), mais apparemment pas lors de la création.

L'avantage de ces triggers, c'est qu'ils interviennent systématiquement, même si le programmeur a oublié le contrôle dans son code. L'inconvénient c'est que comme ils interviennent directement sur l'enregistrement dans la base, pour voir les données réelles à l'écran il faut forcer la relecture des données de la base, en passant à une autre fiche et en y revenant par exemple. Un bouton "Actualiser" dans la fiche serait bien pratique.

Un autre inconvénient qu'il vaut mieux connaître, c'est que lors d'une importation, on ne peut savoir si le N° a été modifié. Ainsi si des N° sont en double dans votre gedcom, le deuxième dans l'ordre de l'importation sera modifié. Cà peut être gênant s'il sert de lien avec Quisontils. Donc il vaut mieux les corriger avant d'exporter en gedcom.

De même si vous faîtes une importation gedcom sur un dossier déjà existant, les clés des nouveaux individus créés risquent d'être modifiées si elles étaient déjà attribuées.

Votre avis: Faut-il automatiser la correction de CLE_FIXE par les triggers comme je le propose ou n'appliquer cet automatisme que pour la création et la modification depuis la fiche (pas lors d'une importation)? Le deuxième choix implique un controle des doublons après importation par la requête et soit une modification du programme par PCM pour vérifier le code lors de la création d'un individu, soit garder les triggers et demander à PCM de proposer en option de les désactiver lors d'une importation gedcom. L'option pourrait s'appeler "Garder les CLE_FIXE". Je serai plutôt partisan de cette dernière solution.

A+

André
Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée. (Loi des Mises à Jour)
 

Hors ligne Ransac

  • Modérateur Global
  • AncestroGrandMaitre
  • *****
  • Messages: 3 015
  • Remercié: 1 fois
    • bases des villes
  • Programme: 2015-1996.3
  • Base: 5.131
  • Système: Windows vista, Windows 7, Windows 10
Recherche cle_fixe non renseignée
« Réponse #14 le: 28 Octobre 2005 à 11:34:35 »
je ne suis pas entré dans ta procédure car je n'y pijerai rien, mais avant de l'exécuter, j'aimerai savoir comment elle attribue la clé très exactement.

mon avis est qu'elle doit d'abord essayer d'attribuer le NIP en tant que clé. Ensuite, si cette clé est déjà attribué à un autre (ce qui ne devrait pas être le cas puisque les NIP sont uniques !) alors elle attribue une clé non utilisée (à partir de la clé 1 si tu veux) !

Est-ce bien ce que fait ta procédure ? et si non, que fait-elle et pourquoi ?
N'oubliez jamais que le mieux est l'ennemi du bien  et que la perfection n'est pas de ce monde !
Les définir est un défi, les réaliser est un leurre !    ... mais on aimerait tellement y croire!
 

Hors ligne DDdeBerdeux

Recherche cle_fixe non renseignée
« Réponse #15 le: 28 Octobre 2005 à 12:24:06 »
C'est presque çà, sauf que l'attribution du NIP ( ou d'un autre code) en tant que CLE_FIXE est faîte par le programme. Le trigger vérifie d'abord si la clé proposée existe. Si elle n'existe pas il l'accepte. Si elle existe, il la remplace par une autre libre en cherchant à partir de 1. Pourquoi je préfère 1: parce que je suis sûr comme celà que ma clé ne dépassera jamais le NIP (ou CLE_FICHE), donc ne sera pas réattribuée par le programme.

A+

André
Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée. (Loi des Mises à Jour)
 

Hors ligne Horemans

  • AncestroSenior
  • *****
  • Messages: 1 775
    • http://perso.wanadoo.fr/philippe.horemans
Recherche cle_fixe non renseignée
« Réponse #16 le: 28 Octobre 2005 à 20:20:35 »
Citation de: "DDdeberdeux"
parce que je suis sûr comme celà que ma clé ne dépassera jamais le NIP (ou CLE_FICHE),


La clé lien PEUT et dans certains cas DOIT dépasser le nip :

Si dans Quisontils, la clé 1000 à été attribuée, que la base à été restaurée par exemple avec un nip de 1 à 800, la clé lien est conservée par la restauration et va donc jusque 1000. Le meilleur moyen de ne pas réattribuer une clé lien déjà existante, c'est au moins de continuer la numérotation des clé lien à partir de 1001. C'est l'objet de ma proposition.



 Je veux bien qu'on réaffecte des numéros qui n'ont jamais été utilisés par Quisontils, mais çà oblige à balyer tous les album à chaque affectation de clé lien. Je doute que les temps de réponses soient optimisés avec de gros albums.

A mon avis une formule mathématique est plus performante qu'une recherche dans des fichiers.
Plus çà va, plus je me régale...  Et avec  Quisontils, la gestion des actes, c'est facile !   Philippe
 

Hors ligne DDdeBerdeux

Recherche cle_fixe non renseignée
« Réponse #17 le: 28 Octobre 2005 à 21:47:51 »
Ce que je veux dire, c'est que le NIP maxi est obligatoirement supérieur ou égal au nombre d'individus dans la base. En recherchant une CLE_FIXE disponible à partir de 1, on en trouvera obligatoirement une d'un code inférieur à ce NIP maxi. Donc la CLE_FIXE proposée par Ancestrologie lors de la création d'un nouvel individu, soit le NIP maxi précédent + 1, ne pourra pas être une des CLE_FIXE attribuées par la méthode exposée et pourra donc être directement acceptée sans recalcul (sauf évidemment si elle existait avant l'importation). Par contre avec ta méthode, dès que le NIP arrivera à 1000, la clé proposée par Ancestrologie sera systématiquement refusée et devra être recalculée. D'accord avec toi pour dire que ta méthode de calcul serait plus rapide, mais elle interviendrait plus fréquemment. Et puis pas de panique, d'après mes tests, sur une base de 6000 individus qui auraient presque tous sauf les derniers déjà une CLE_FIXE, obligeant donc à balayer toute la table avant de trouver un N° disponible, il faut 0,4s. Et d'après ce que j'ai pu lire sur ce forum, le nombre de doublons trouvés n'est pas si énorme, donc le calcul ne serait pas fait très souvent. Je vais quand même rechercher s'il n'y aurait pas des méthodes SQL plus rapides que le COUNT() pour savoir si la clé existe déjà, je débute en SQL.

A+

André
Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée. (Loi des Mises à Jour)
 

Hors ligne Gvx

  • AncestroJunior
  • ****
  • Messages: 361
Recherche cle_fixe non renseignée
« Réponse #18 le: 28 Octobre 2005 à 22:42:38 »
Citation de: "DDdeberdeux"
je débute en SQL.




Bonsoir André,





Vu le nombre de propositions d'amélioration des procédures stockées et requêtes SQL: Les débuts sont prometteurs :D