forum Ancestrologie
Ancestrologie - Plugins et Outils => BOA => Discussion démarrée par: mascouche le 25 Septembre 2006 à 22:02:36
-
Est-il possible de générer une liste triée sur le numéro Sosa? J'imagine que oui, mais ma connaissance étant limitée, j'apprécierais que quelqu'un m'aide.
Merci!
-
Bonsoir, celle-ci te convient-elle :?:
(https://forum.ancestrologie.org/proxy.php?request=http%3A%2F%2Fwww.jipschiff.com%2Fimages%2Fascendance.gif&hash=1b212558b0462213963929cde38d1b5f4235e566)
-
En fait cette liste est parfaite... Le problème c'est que ce n'est pas ce que je veux...
Je me suis très mal exprimé... Ce n'est pas un tri sur le numéro Sosa que j'ai besoin, mais bien une liste triée sur le NIP.
Le Sosa trie à l'intérieur d'une ascendance, je veux trier à l'intérieur de ma base de données.
-
select CLE_FIXE as NIP, NOM , PRENOM from individu where kle_dossier=1 order by CLE_FIXE
avec klé_dossier à changer en fonction de ton fichier
-
Quand j'exécute cette requête, j'obtiens une liste de tous les individus de ma base de données triés selon le NIP. Exactement ce que je voulais. Mais...
Ma base est composée de 7178 individus, ma liste en compte 7178 = Excellent
le dernier NIP entré dans ma base est le 11148, le dernier NIP listé est le 11146 = OUPS (que se passe-t-il?)
Tous les individus doivent avoir un NIP. Pourtant ma liste indique que seulement 1161 individus ont un NIP... HUMMM... Pourtant quand je regarde individuellement la fiche d'un individu qui n'est pas supposé avoir un NIP (selon la liste générée par la requête) il y a un NIP.
La question que je me pose: la requête proposée est-elle juste? Si oui, pourquoi la liste générée est-elle erronée?
Aidez-moi SVP, je ne comprend absolument rien aux requêtes SQL.
Merci infiniment!!
-
Bonjour,
Philippe, faudrait arrêter de confondre CLE_FIXE, CLE_FICHE et NIP.
Ce que l'on appelle NIP dans Ancestrologie, c'est CLE_FICHE, parfois précédé du N° de dossier.
CLE_FICHE est le seul réel identifiant de l'individu (chaque individu en a un et il est unique dans toute la base).
CLE_FIXE est une clé créée pour assurer un lien avec QuiSont'ils. Il n'a donc rien d'obligatoire.
A+
André
-
WOW
ça fonctionne très bien...... MERCI!!!!!
-
faudrait arrêter de confondre CLE_FIXE, CLE_FICHE et NIP.
Il n'y a pas confusion dans mon esprit, je sais que les champs peuvent être différents, mais il il y a erreur de ma part due au fait que chez moi et depuis toujours, ces champs ont la même valeur car je n'ai jamais ni réinstallé ni réimporté quoi que ce soit depuis que j'utilise Ancestro.
Pour éviter ce genre d'erreur et pour faciliter l'exploitation des tables par SQL par un utilisateur lambda, il faudrait pouvoir avoir une nomenclature des champs des différentes tables avec la définitions des champs essentiels que sont les clés.
Ceci a été demandé il y a fort longtemps, mais c'est un travail qui ne peut être fait que par quelqu'un ayant une bonne connaissance des tables.
-
Est-il possible de sauvegarder le libelle de la requête (select CLE_FICHE as NIP, NOM , PRENOM from individu where kle_dossier=1 order by CLE_FICHE) ?
pour le résultat, pas de problème...
-
Il y a toujours la possibilité de sauvegarder le requête dans un fichier .txt et quand le BOA est ouvert d'importer cette requête.
-
si le NIP ne correspond pas exactement au nombre d'individus , c'est parce que le NIP est incrémenté de 2 à chaque création d'individu
(incrémentation automatique de 1 dans la base et probablement de 1 par programmation)
erreur signalée depuis longtemps
-
(incrémentation automatique de 1 dans la base et probablement de 1 par programmation)
Bonjour,
Non, uniquement par programmation. Il n'y a pas d'incrémentation automatique de CLE_FICHE par la base. Il y a bien un générateur qui donne le N°, mais il est incrémenté uniquement par le logiciel. Mais pourquoi 2 fois?
A+
André
-
Regardez mieux comment cela se produit, si je créé un individu, je l'enregistre, puis je créé un autre, je l'enregistre également, le NIP n'augmente que d'1 !
Dans quels cas ou situation augmente-t-il de 2 ??
-
j'ai refait un essai en créant les parents d'un ancêtre
le père a le NIP 4318 et la mère 4320 puis
création d' un nouvel individu sans l'enregistrer (annuler)
puis un autre en l'enregistrant celui la a le NIP 4323
(ancestro v547 b4.043)
j'ai fait la mise à jour v576 et b4.051
et là miracle le problème est corrigé (nouvelle saisie rapide)
une petite anomalie qui datait de 2004 enfin corrigée
-
Essai transformé :lol: :lol: :lol:
-
...création d' un nouvel individu sans l'enregistrer (annuler)
puis un autre en l'enregistrant celui la a le NIP 4323...
Attention dans le cas d'une anulation, la création à suivre sera incrémentée de 2, l'annulation a réservé un N°.
André, c'est la proc IBSpClefUnique qui donne le NIP.
-
Attention dans le cas d'une anulation, la création à suivre sera incrémentée de 2, l'annulation a réservé un N°.
André, c'est la proc IBSpClefUnique qui donne le NIP.
non il semble qu'avec la nouvelle saisie rapide l'incrément reste à 1 même si on fait fermer (il n'y a plus de bouton annuler)
pour revenir à l'ancienne version :
j'ai fait
select cle_fiche from individu where kle_dossier=1
order by cle_fiche
voici ce que j'obtiens pour cle_fiche
de 1 à 4174 incrément de 1
de 4174 à 4320 incrément de 2 (ce qui correspond à des versions d'Ancestro de début 2004 jusqu'à la version v547 b4.043 )
puis 4323 à 4326 incrément de 1 version 576 b4.051
-
André, c'est la proc IBSpClefUnique qui donne le NIP.
Cà c'est la procédure delphi qui doit faire la requête:
select CLE_UNIQUE from PROC_GET_CLEF_UNIQUE(:nomtable).
Mais si tu es vraiment très pressé, tu fais la requête:
select gen_id(GEN_INDIVIDU,1) from RDB$DATABASE
pour avoir une nouvelle clé pour un individu :wink:
A+
André
J'aurais pas dû l'écrire, il y en a qui vont tester et qui auront ensuite des trous dans leur numérotation. Et les trous dans les N°, çà ne plaît pas aux comptables :cry:
-
...Cà c'est la procédure delphi qui doit faire la requête:
select CLE_UNIQUE from PROC_GET_CLEF_UNIQUE(:nomtable).
Oui, je me suis fourvoyé, la prochaine fois j'irai dormir plus tot, et pour la version c'est pareil, elle était pas de première jeunesse !!! :oops: :oops: