En des temps anciens (*) il fallait économiser l'espace disque, aujourd'hui il faut le remplir !

Je suis récemment intervenu sur un développement pour un problème de performances d'accès aux données Hyper File exploitées en mode client/serveur. Une interrogation de la base devant donner quelques centaines d'enregistrements, sur quelques centaines de milliers au total, prenait un temps trop important en production. Il s'agissait d'une interrogation "multicritères" faite via une requête paramétrée. Le problème a été vite réglé grâce à l'option "Optimiser la requête" : des index manquaient dans la table.

Ma surprise a été de constater que le développeur en charge de cette partie du projet avait volontairement omis la création de certaines clés, afin de limiter l'espace sur disque occupé par l'index du fichier de données. Noble attention héritée d'un réel soucis de manque d'espace d'il y a quelques années, mais qui ici a provoqué une gêne des utilisateurs.

Le coût du stockage est tel aujourd'hui qu'il ne faut pas se priver d'index, et de tout ce qui peut permettre de retrouver plus vite l'information pour mieux servir l'utilisateur final !

Attention, il peut être tentant de généraliser cet usage "libéral" de l'espace disque à l'espace mémoire. Même s'il n'est pas rare de compter la RAM en Go et non plus en Mo, il faut tout de même rester raisonnable dans l'utilisation de la RAM.


(*) dans notre "espace temps" d'informaticiens, les "temps anciens" ne correspondent qu'à très peu d'années des humains.

Simple, toujours faire simple !

J'ai pu lire le message si dessous sur un forum aujourd'hui même :

8<----------------------------
Je veux créer une classe controleur qui encapsule les pointeurs vers des objets qu'elle crée et stocke dans un tableau de vectors.
8<----------------------------

Dans cette question technique le besoin de l'utilisateur réel, celui de l'utilisateur final, n'apparaît pas. Cela ne fait aucun doute, car c'est la clé de voûte du succès de WINDEV, il y a pourtant un moyen simple de parvenir à satisfaire le besoin de l'utilisateur sans programmation complexe.

Il faut se demander ce dont à besoin l'utilisateur, et uniquement à partir de là en déduire avec lui l'interface dont il aura besoin. Créer un bon schéma regroupant ses modes opératoires, le code à produire derrière coulera de source grâce à la richesse du WLangage. Telle est la philosophie pour réussir à coup sûr un développement avec WINDEV !

Ndlr : je ne veux surtout pas être moralisateur, et encore moins donner l'impression de détenir la Vérité, car la plupart de mes billets sont inspirés de mes propres erreurs. J'espère juste faire passer le message : "penser à faire simple" ! Ce qui n'est pas facile dans les journées souvent sur-chargées faites par les développeurs.

Expliquer les erreurs, ne pas contourner à tout prix...

Le thème technique de ce billet porte sur la gestion de l'identifiant automatique d'un fichier Hyper File (principe/panne). Le thème plus général reste le développement tête dans le guidon, vivement déconseillé dans la mesure du possible.

Les fichiers Hyper File proposent un "identifiant automatique" qui permet d'attribuer à chaque enregistrement un numéro unique. Il est incrémenté à chaque ajout, une valeur attribuée n'est jamais réutilisée même après une suppression (contrairement au numéro de l'enregistrement).

Il m'est arrivé sur un site en exploitation d'avoir une erreur de doublon sur cet identifiant automatique. Dans pareil cas, une possibilité serait de contourner immédiatement par un traitement forçant l'ajout, urgence d'une programmation tête dans le guidon, code vu aujourd'hui sur un forum. Mais une bien meilleure démarche, consiste à se documenter sur le principe de fonctionnement, afin de connaître les causes possibles.

Le principe de gestion de l'identifiant automatique est le suivant (information émanant directement du support PC SOFT) :

8<----------------------------
Le calcul du numéro d'identifiant utilise l'entête du fichier Hyper File pour stocker le dernier identifiant utilisé. L'ajout d'un nouvel enregistrement déclenche les traitements suivants :
1. Lecture du dernier identifiant ID dans l'entête
2. Calcul du nouveau identifiant, ID = ID + 1
3. Ajout du nouvel enregistrement
4. Mémorisation de l'identifiant (écriture dans l'entête).
8<----------------------------

Une erreur de doublon, provient d'un défaut d'écriture entre les étapes 3 et 4, c'est donc une panne (disque, réseau...) uniquement qui peut provoquer l'erreur, il est donc déconseillé voir dangereux de tenter un contournement par programmation. Le doublon est dans ce cas la manifestation visible de la panne, les conséquences peuvent être bien plus coûteuses en conséquences.

La solution à court terme consiste à réviser le fichier avec l'option numéro 5 du programme WDOPTIMISEUR, puis à augmenter le mode de sécurité de l'application par l'appel de la commande suivante : HSécurite(2)

Il faut ensuite diagnostiquer la panne par une expertise des installations. Dans le cas auquel j'ai été confronté, qui remonte à quelques années, il s'agissait de l'utilisation d'un poste Windows 98 qui avait servi de serveur de données malgré mes spécifications d'installation qui imposaient un Windows serveur.

C'est lent ... mais pourquoi ?

Il arrive qu'un code mis au point ne donne pas son résultat assez rapidement. Pire, il peut arriver qu'un code opérationnel depuis longtemps ralentisse soudainement. Ce dernier cas m'est encore arrivé la semaine dernière, une fenêtre ayant un chargement de données en arrière plan (thread) c'est vue ralentie soudainement, plus d'une minute de chargement au lieu des quelques secondes habituelles.

Une exécution de la fenêtre avec l'analyseur de perfor- mances à immédiate- ment permis de localiser le ralentis- sement. Un appel de la fonction "INILit" prenait à lui seul 46 secondes ! Farce de l'administrateur réseau qui avait supprimé une ressource partagée par erreur.

Réflexe à prendre donc, ne pas omettre un passage par l'analyseur de performances dès que la vitesse n'est pas au rendez-vous !