Sécurisation des données - Partie 1
Si on veut "blinder" son code les fonctions WD Hajoute(), Hmodifie() et Hsupprime() nécessitent des tests après exécution. Ces tests sont nécessaires afin d'empêcher qu'une application continue à fonctionner avec des problèmes dans les données ... et fasse d'autres dégats plus loin.
Code "en dur" :
Tester les doublons et l'intégrité permet de garantir l'intégrité de la base. Ces tests doivent être faits lors de chaque opération de mise à jour.
Un peu mieux : l'écriture de fonctions
Bien entendu ce bout de code doit faire l'objet d'une fonction afin d'éviter d'écrire 15 lignes là où on pourrait en écrire une seule. Il sufft de reprendre le bout de code ci-dessus et de remplacer ARTICLE par un paramètre transmis à la fonction : PROCEDURE bModifie(sFichier)
Une procédure spécialisée dans la gestion de fichiers :
On peut donc écrire les trois fonctions de mise à jour : bAjoute(), bModife() et bSupprime(), ces trois fonctions testant systématiquement les erreurs et retournant un booléen.
Implémentation des transactions :
Cependant on peut aller plus loin en utilisant systématiquement les transactions. Les transactions permettent de mettre à jour les fichiers uniquement si l'intégralité du traitement a été réalisé avec succès.
Par exemple : je dois créer un entête de facture suite à la création de N lignes de factures. Que se passe t'il si le traitement se plante au beau milieu de l'écriture des lignes de factures ?
Et bien on va se retrouver avec des enregistrements de lignes de factures orphelins ! Il est possible que ça n'ai pas d'incidence ... mais il est aussi possible que ça "foutte la merde" dans un état, un calcul ou un traitement ! Combien de temps passé à rechercher ce genre de problèmes chez un client suite à un code de mise à jour mal ficelé ?
Avec l'utilisation des transactions soit tout est mis à jour, soit rien n'est mis à jour ! C'est noir ou blanc ... et pas gris clair.
Voici un exemple de code sans transaction (volontairement sans aucun test d'erreurs) :
Que se passe t'il s'il y'a une erreur lors de l'écriture de la 3ème ligne de détail ? L'appli va planter, toutes les lignes de détail ne seront pas écrites et le cumul de la facture ne sera jamais alimenté. Il s'agit là de code "passoire".
Le même traitement avec mise en place des transactions :
Certes avec la syntaxe Windev native c'est plus long à écrire mais cette manière de faire GARANTIE la sécurité et l'intégrité des données. Comme je l'ai dis plus haut dans cet article, tout doit être mis en oeuvre pour éviter de devoir aller "bidouiller" les données chez les clients : perte de temps et insatisfaction client.
NOTE : le début et le fin de transaction doivent être placés le plus prêt possible du début et de la fin des opérations de mises à jour.
Dans le prochain article je proposerai une collection de procédure adaptée.