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

[Invité Notpa]

Autre test : j'ai essayé de définir la zone plieur en type Binary. Dans ce cas, il n'y a pas de conversion et la comparaison se fait octet par octet. Le problème est qu'une clef dans Acess ne peut pas être associée à une zone de type Binary (msg d'erreur dans Acess quand je crée la clef) !

Par contre, je n'ai pas testé avec du SQL. Peut-être que le critère de sélection accepte le binaire. Je vais tester.

[Invité Notpa]

Bonjour à tous !

J''AI TROUVÉ !!!

J'ai ajouté un champ dans la table DK-ref que j'ai appelé plieur_asc. Ce champ contient une conversion en ASCII du champ contenant le nom du plieur. Comme la valeur ASCII d'une lettre en majuscule est différente de la même lettre en minuscule, je ne peux pas avoir de doublons. Donc, la recherche du plieur dans la table DK-ref se fait sur le champ en ASCII et non sur le nom du plieur en texte.

Avec la recherche de nono, j'ai les champs (dk-ref, plieur format texte, plieur format ASCII) : 1533 - nono = 110111110111
Et avec  NoNo, j'ai les champs : 6006 - NoNo = 7811178111

Je n'ai plus qu'à incorporer la routine de conversion dans les programmes et ça résoudra le problème de doublons passés et à venir.

[nthor]

Comme quoi la nuit porte conseil

[Kana-chan]

@Notpa,

Je voulais dire que le champ qui correspond au nom du plieur ne doit pas être une clef, ni primaire, ni secondaire. Je ne rencontre pas ce problème sur ma base Access.

Voilà ...

[Invité Notpa]

Bonjour Kana-chan.

Le champ plieur n'a pas de clef. Le problème venait de la conversion des majuscules en minuscules dans la recherche SQL. C'est confirmé par plusieurs sites sur le Net. Donc, je garde ma méthode qui ne pose pas ce problème, le SQL trouve le bon plieur.

[DK-]

Il y a 2 heures, Notpa a dit :

J''AI TROUVÉ !!!

Super ! Mais je n'en doutais pas.

 

[Invité Notpa]

Hello !

Mon programme d'initialisation de la base de données Kana se plante car le fichier Kana contient une ligne qui n'a pas de nom de plieur :

Citation

8694    841183    [Clubic]_Jean_Michel                    2438        16
8695    841292    jordan                            2436        19
8696    841328    [PCA]thibaut                        2436        24
8697    841358                                2436        19
8698    841541    MacGawel                        2434        111
8699    841605    [inpact]_Nargzul                    2433        10

Est-ce normal ? Comment est--ce possible ?

[DK-]

Kana a modifié son script le 05/11 pour éviter cet écueil. Il s'appelle désormais Nom vide (ref=8703).
edit : tu peux le voir sur le fichier d'aujourd'hui :

8699	842057	Nom vide						2436		19

D'autre part, il y a quelques corrections à apporter au fichier des dk-ref (mon Calc m'a transformé certains identifiants) : vois stp ici pour ces corrections (pour le moment, le temps que je te ré-uploade un fichier complet).

Modifié le 15 novembre 2019 par DK-
lien fichier d'aujourd'hui

[Invité Notpa]

OK. Vu que la recherche des zones (pos, folding, plieur, points, WU) est basée sur les tabulations dans le fichier texte, je n'ai aucun moyen de savoir si une zone est absente, que ce soit les noms de plieurs comme les points ou les WU. Il est donc impératif que le fichier des Kana soit correct et complet.

Pour mes tests, j'ai changé le fichier à la main.

Pour tes DK-ref, je travaille en ce moment avec une liste qui est obsolète. Ça me suffit. Mais lorsque tout sera OK, je te demanderai les derniers fichiers à jour.

[DK-]

il y a une heure, Notpa a dit :

Pour tes DK-ref, je travaille en ce moment avec une liste qui est obsolète. Ça me suffit. Mais lorsque tout sera OK, je te demanderai les derniers fichiers à jour.

La voici (re-vérifiée par Nthor) :

liste txt des 19290 dk-réf (par id-dk et id-kana) au 15nov2019 (sauf les 406 supprimés en octobre 2018) :
www.casimages.com/fi/1911150654102322384532.txt.html