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

[DK-]

Je suppose que les dk-réf ne sont pas rechargées chaque jour  ?
Elles peuvent être conservées, elles ne changeront évidemment jamais (sauf à en ajouter de nouvelles comme tu l'as déjà prévu).

Modifié le 11 novembre 2019 par DK-

[Invité Notpa]

il y a 11 minutes, DK- a dit :

Je suppose que les dk-réf ne sont pas rechargées chaque jour  ?

Non. Tout comme les actifs. Le temps pris pour les afficher est juste le temps de lire la BdD et de remplir la grille.

[Invité Notpa]

Résultat de la mise à jour de 500 enreg. Kana :

Pas mal, non ? Je ne peux pas faire mieux. Le temps de chargement dans les grilles est donc le plus long.

[Invité Notpa]

Hello DK_ !

J'ai une idée. Si si, ça m'arrive parfois !

Puisque le temps de mise à jour est rapide et que l'affichage des Kana est long, que penses-tu de n'afficher par défaut que les plieurs actifs (actifs dans l'année) dans les listes ? Cela réduira le temps de chargement. Il n'y aura que 294 lignes au lieu de 18.885. Bien sûr, un menu permettra d'afficher la totalité, actifs ou pas.

Ça te va ou as-tu besoin de voir toujours  la totalité des Kana ?

[DK-]

Hi Notpa,

Hélas non, je crains que ça soit impossible. Car si on ne charge que ceux déjà connus pour être actifs, on rate justement :
- les nouveaux (et il y en a tout de même eu 41 sur les 12 derniers mois),
- les « retours » (ex. très récents : vetdepro (ref=8244) le 04/11, ewaca (ref=5436) le 09/11 et GoJiTa972[Clubic] (ref=296) le 10/11).

Évidemment, ils ont été signalés sur cette page de Kana (ie. le jour de leur arrivée, affichés en blanc dans la colonne « 1 jour », comme le sont aujourd'hui Sandrava (ref=33) et DonEusebio (ref=123)). En effet, Kana attribue effectivement lui aussi un statut d'activité, mais à 7 jours seulement ! Ce qui est très intéressant par d'autres côtés, mais provoque au quotidien une sacrée quantité d'allers-retours dans son statut actif/inactif !
Si on envisage de ne charger automatiquement que « nos » actifs d'ici (ie. à un an), et que je doive moi-même comparer avec la page de Kana pour surveiller quotidiennement nouveaux et retours, qui seraient donc à rentrer manuellement, la quantité de ces vérifications quotidiennes sera totalement ingérable pour moi (et me demandera presque autant de temps que le chargement automatique du fichier du jour) !

Pour l'instant, je ne vois pas trop comment optimiser le temps de chargement. Tant pis, je lancerai ton soft au tout début de mon heure quotidienne sur les stats...

[Invité Notpa]

OK. J'abandonne cette idée.

[Invité Notpa]

Hello DK- !

Ça avance. Je finalise la création de la table avec la totalité des entrées. Mais gros problème : dans les DK-ref, j'ai 2 plieurs qui ont le même nom :

• 1533    nono
• 6006    NoNo

Comme le programme ne sait pas tenir compte des majuscules, pour lui, c'est pareil. Du coup, quand je crée la relation entre un plieur dans Kana avec son nom dans DK-ref, ces deux plieurs différents ont la même DK-ref, la première trouvée pour nono, soir 1533..

Qu'est-ce qu'on fait ?

PS : aucun rapport avec Nono qui est mon surnom pour beaucoup de mes proches !

[Invité Notpa]

Précision : dans mon programme, si je fais une comparaison :

IF "nono" = "NoNo", le retour est Faux. Mais lorsque je stocke le nom du plieur dans la base de données, MS Acess perd la notion de 'case sensitive'. Du coup, j'ai un doublon lors de la création de la table DK-ref (le nom du plieur est une clef pour accéder rapidement à une entrée de la table) et celle-ci n'accepte pas les doublons.

:chpas:

 

 

 

[DK-]

Salut Nono ! 

Il y a 1 heure, Notpa a dit :

dans les DK-ref, j'ai 2 plieurs qui ont le même nom

C'est pire ! Regarde bien, il y a 16 « doublons à la casse près » :

1.     [PPC]_thib  (ref=14199)    et     [PPC]_Thib  (ref=17746)
2.     Cha  (ref=84)    et      cha  (ref=18613)
3.     clement  (ref=3360)    et      Clement  (ref=9282)
4.     dob  (ref=910)    et      Dob  (ref=9614)
5.     Domieuh  (ref=3470)    et      domieuh  (ref=10719)
6.     M  (ref=11320)    et      m  (ref=18625)
7.     n  (ref=4137)    et      N  (ref=17318)
8.     nono  (ref=1533)    et      NoNo  (ref=6006)
9.     Pierre  (ref=5655)    et      pierre  (ref=18720)
10.     S  (ref=9288)    et      s  (ref=13410)
11.     Shivers1081  (ref=6195)    et      shivers1081  (ref=13271)
12.     Sovxx  (ref=1721)    et      sovxx  (ref=16101)
13.     stephane  (ref=2091)    et      Stephane  (ref=6471)
14.     Sylvain  (ref=1790)    et      sylvain  (ref=6041)
15.     T  (ref=11)    et      t  (ref=15581)
16.     Xavier  (ref=2593)    et      xavier  (ref=6038)

 

il y a 47 minutes, Notpa a dit :

Moi non plus...

[Invité Notpa]

Hello !

Je n'ai pas vu les autres car au premier rencontré, j'ai accepté les doublons, donc les autres sont passés.

J'ai fait des recherches sur la Net. Pas évident. Les clefs dans Acess en mode Unique ne tiennent pas compte des majuscules, donc nono = NoNo. Il y a un moyen c'est de définir les champs en mode binaire, et pas en mode texte. Mais Acess n'accepte pas les clefs binaires !!!

Je cherche un moyen.