Simplifier les mises à  jour avec les MODS

1. Atteindre le fichier pour obtenir les valeurs courantes de l’enregistrement
demandé Je ne verrouille pas l’enregistrement parce que d’autres programmes devront
peut-être l’utiliser pendant la mise à  jour interactive.

2. Afficher les champs à  modifier par l’utilisateur.

3. Revenir au fichier, obtenir l’enregistrement et le verrouiller.

4. Mettre à  jour les champs du fichier et mettre à  jour l’enregistrement.



Même des programmes de mise à  jour simples soulèvent quelques interrogations



Difficile d’imaginer plus simple ! Mais, même des programmes de mise à  jour simples
soulèvent quelques interrogations. La figure 1 présente la structure du fichier
SLP001P, un fichier de contact de vendeurs. J’utilise SLP001P et un programme
de maintenance pour répondre à  une question : Dois-je utiliser dans le fichier
écran les mêmes noms de champs qui existent dans le fichier base de données ?
On distingue deux approches pour les noms de champs dans le DDS pour le fichier
écran :



1. Utiliser les noms de champs dans le fichier écran qui correspondent aux noms
de champs de base de données. La figure 2 montre des parties du code DDS pour
le fichier écran de maintenance et on constate que les noms de champs correspondent
aux noms de champs de base de données.

2. Utiliser des noms de champs différents dans le fichier écran. Dans ce cas,
après avoir extrait l’enregistrement du fichier base de données, il faut transférer
les valeurs champs de base de données dans les champs d’écran. Ensuite, après
avoir obtenu à  nouveau l’enregistrement de base de données, il faut transférer
les valeurs des champs d’écran dans les champs de base de données.



La première méthode semble préférable parce qu’elle nécessite moins de ligne de
code. La seconde demande deux lignes de code pour chaque champ utilisé dans le
fichier écran: une ligne pour déplacer la valeur de la base de données au champ
d’écran, et une autre pour effectuer le déplacement inverse.



Toutefois, la première approche présente une difficulté. Il n’y a qu’une valeur
courante pour chaque champ interne. La figure 3 montre une suite d’opérations
sur le nom de champ interne FNAME. Avant que l’enregistrement ne soit extrait,
FNAME est vierge. Après l’extraction, FNAME a la valeur « Jim ». Quand l’écran s’affiche,
l’utilisateur change la valeur de FNAME en « James ». Mais, avant que l’enregistrement
ne soit mis à  jour, une autre extraction a lieu, qui rétablit la valeur  » Jim
 » initiale pour le champ FNAME! Il faut donc avoir le moyen de préserver les valeurs
des champs d’écran avant d’extraire à  nouveau l’enregistrement de la base de données,
et effectuer cela dans une ligne de code.



La solution est fournie par une MODS décrite en externe. La figure 4 montre les
deux morceaux de code pour l’utilisation de cette MODS. L’ensemble de cartes I
définit la structure de données, et l’ensemble des cartes C montre comment la
MODS est utilisée pendant l’opération de mise à  jour.



A la ligne 18 de la figure 4, le E en position 7 de la déclaration de structure
de données @SAVE signifie qu’un fichier externe définit sa structure. Dans notre
cas, la structure de @SAVE est définie par le fichier SLP001P.



En décrivant en externe la structure de données @SAVE, je fais correspondre les
champs de la structure de données à  ceux du format d’enregistrement du fichier.
Cette correspondance des structures est importante du fait que la structure de
données va servir à  mettre à  jour les champs du fichier base de données.



On pourrait définir la structure @SAVE sans utiliser une référence de fichier
externe, en tapant dans To et From pour chaque champ du fichier ou en tapant simplement
les champs d’écran qui sont utilisés pour le fichier. Cependant, si on apporte
des modifications au fichier ou à  l’écran, il faut maintenir la structure de données.
Il vaut mieux fonder la structure de données sur la description externe du fichier.




A la ligne 19, le champ SLPNR est renommé XLPNR dans la structure de données.
Remarquons dans la figure 1 que le champ SLPNR est la clé du fichier SLP001P.
Le reste des champs dans la structure de données est nommé de la même manière
que dans le fichier SLP001P. J’explique plus loin pourquoi le champ clé est renommé.



Pour utiliser la structure de données @SAVE, examinons le deuxième bout de code
dans la figure 4. A la ligne 494, les valeurs de champ proviennent du fichier
écran et sont partagées avec la première occurrence de la structure de données
@SAVE. Pour sauvegarder les valeurs courantes avant d’extraire l’enregistrement
du fichier avec la commande CHAIN, on rend courante la seconde occurrence de la
structure de données, sauvegardant ainsi les valeurs de champ de l’écran dans
la première occurrence.



Toutes les valeurs de champs, à  l’exception du champ clé SLPNR, changent maintenant
en fonction des valeurs de champs dans la seconde occurrence de la structure de
données @SAVE. Pourquoi la valeur SLPNR n’est-elle pas modifiée ? Parce qu’en
ligne 19 du code, le champ de la structure de données SLPNR est rebaptisé XLPNR.
Il s’en suit qu’on peut utiliser la valeur SLPNR du champ du fichier écran (qui
ne peut pas changer parce que c’est un champ en sortie seulement) pour chaîner
(CHAIN) au fichier comme le champ clé de la ligne 495. Si SLPNR n’était pas renommé
dans la structure de données, la valeur de SLPNR serait inconnue quand on appellerait
la seconde occurrence à  la ligne 494.



A la ligne 496, la première occurrence est rappelée, remplaçant les valeurs des
champs dans le fichier. Enfin, le fichier est mis à  jour à  la ligne 497.



La mise à  jour est donc effectuée sans aucune instruction MOVE avant ou
après la commande CHAIN



La mise à  jour est donc effectuée sans aucune instruction MOVE avant ou après
la commande CHAIN. Les deux instructions OCUR en 494 et 496 dispensent d’un MOVE
en sauvegardant les valeurs d’écran dans la première occurrence de la structure
de données. Remarque : Après un CHAIN réussi, la seconde occurrence de la structure
de données contient les valeurs originales de la base de données avant la mise
à  jour. Il est donc possible d’utiliser une option undo ou autre option pour examiner
les valeurs de champs d’origine.



En utilisant des MODS fondées sur la structure du fichier base de données que
l’on maintient, on peut simplifier le coding et la maintenance en utilisant les
mêmes noms de champs dans le fichier écran que ceux qui existent dans le fichier
base de données. Bonne programmation avec les MODS !