« Kana-bis », le programme de gestion des données Kana-chan

[nthor]

Je ne connais pas la logique de ton programme donc je ne sais pas si c'est possible mais utiliser les DK-refs comme  clés ne serait pas une solution ?

[DK-]

Si j'ai à peu près compris les épisodes précédents, il me semble que la base de Kana est aussi sous Access.
Faudrait lui demander comment il gère la casse.
Sauf que sans les notifs mail, il ne repassera ptêt pas avant demain...

[Invité Notpa]

Hello nthor !

Citation

utiliser les DK-refs comme  clés ne serait pas une solution ?

C'est justement ce qui coince ! Pour associer à un kana une DK-ref, il faut que j'accède à la table des DK-ref via le nom du plieur. Mais il y a des doublons. Dans la table Acess DK-ref, la zone des plieurs est bien case-sensitive. Par exemple, le pseudo nono est bien codé nono et le NoNo est bien indiqué NoNo. Mais quand je fais une recherche via la clé associée au nom du plieur, la clé a la valeur nono dans tous les cas, donc je tombe toujours sur le premier.

J'ai essayé via une instruction SQL SELECT, mais pareil : la comparaison se fait toujours sur nono, même si le critère SQL est NoNo.

Le seul moyen est de scanner la table des DK-ref à chaque kana lu.  Mais au maximum, ça fait 18896 * 18884, soit 356.832.064‬ scans ! Horrible !

Si tu as une idée qui résout le problème, je te paie une mousse !

[nthor]

Je ne suis pas expert en sql et je n'ai jamais touché ni à une base Access ni à Visual basic donc pas sûr que je vais pouvoir t'aider
Je suis tombé là dessus mais je ne sais pas si c'est utilisable.
Sinon, comme le dit DK-, Kana-Chan aura peut être une solution quand il passera dans le coin.

[Invité Notpa]

Merci du lien (que j'avais déjà lu). Mais le problème est dû pas au champ lui-même, mais à la valeur dans la clé, qui elle n'est pas case sensitive.

Je continue à creuser pour trouver une alternative.

[Invité Notpa]

DK-, question bête. A quoi sert la DK-ref (à part mettre la grouille dans mon programme (:lol:) ? Le n° de plieur de Kana ne suffit pas ?

[Kana-chan]

Bonjour,

Dans ma base Access, le nom des plieurs sont dans des champs Text.
Ce champ n'est pas une clef de ma base.

Voilà ...

 

[Kana-chan]

@Notpa,

Tu peux très bien avoir une table avec en clef unique les DK-ref et en champ Text les noms des plieurs.
Dans les autres tables, tu crées un identifiant unique en clef et dans un second champ tu y mets la DK-ref qui provient de la table ci-dessus.

Après, tu peux jouer avec des Select comme SELECT * FROM table2 where colonne_DK-ref.table2 == colonne_DK-ref_clef.table1 AND colonne_Nom_Plieur.table1 IS "NoNo"; ou un truc du genre.

Voilà ...

[DK-]

Merci Kana !

 

@Notpa :

il y a 58 minutes, Notpa a dit :

DK-, question bête. A quoi sert la DK-ref (à part mettre la grouille dans mon programme (:lol:) ? Le n° de plieur de Kana ne suffit pas ?

Il N'Y A PAS de « numéro de plieur de Kana » ni même de numéro de Stanford ! Sinon je ne me ferais pas autant ch... et surtout je ne vous bassinerais pas.
Les deux premières colonnes de nombres dans les txt de Kana (Pos et Folding) correspondent aux rangs quotidiens de chaque plieur, dans la team AF et dans l'ensemble des plieurs.
Et ces deux rangs changent tous les jours !!

ex : [Zebulon.fr]_pustelnik (ref=134)
date     Pos   Folding
14/11 : 48    7139
13/11 : 49    7161
12/11 : 49    7180
11/11 : 50    7208
10/11 : 51    7221
09/11 : 52    7244
08/11 : 52    7255
07/11 : 52    7279
06/11 : 52    7306

Alors, convaincu ?
J'aime assez mettre ma zone partout, mais pas au point où tu le supposes...

[Invité Notpa]

@DK-

OK. Je comprends mieux.

@kana-chan

Bonsoir ! Merci de te pencher sur mon souci.

Il y a 1 heure, Kana-chan a dit :

Tu peux très bien avoir une table avec en clef unique les DK-ref et en champ Text les noms des plieurs.
Dans les autres tables, tu crées un identifiant unique en clef et dans un second champ tu y mets la DK-ref qui provient de la table ci-dessus

C'est ce que je fais. Quand je lis un enreg. de ton fichier Kana, je fais une recherche dans la table des DK-ref  basée sur le nom du plieur qui a une clef secondaire. Et c'est là où ça coince : La commande SEEK = "plieur" qui contient le nom du plieur issu du fichier Kana transforme le mot-clef de recherche en remplaçant les majuscules par des minuscules. C'est un défaut dans VB6. Du coup, si je fais un SEEK sur Nono, il me retourne le premier enregistrement qui contient... nono. Donc dans la table Acess des Kana, le plieur a la mauvaise DK-ref.

En SQL, pareil. Si je cherche NoNo, il remplace les majuscules par des minuscules et me retourne donc nono.

J'ai essayé de me baser dans la table DK-ref avec le nom du plieur comme clef unique. Ça ne va pas à cause de la transformation des caractères. Une clef unique ne peut pas avoir plusieurs entrées différentes.

Donc, pas de solution pour le moment. Mais je suis têtu ! Je trouverai bien un moyen.