Discussion :

[mutsum1]

Bonjour,

J'ai une erreur de mise à jour en cycle GAP. J'ai analysé le problème et j'ai compris pourquoi ça ne marchait pas, mais il me semble pourtant que le principe mis en place est bon.

Voilà mon programme, on peut difficilement faire plus simple.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
H            Y                                         
FYPLTARL1UP  E           K        DISK                 
 *                                                     
IàPLTAR1                                               
I                                              DZBOCEL1
I                                              DZBMCEL1
I                                              DZBLCEL1
 *                                                     
CL1         DZJ2S1    IFEQ 'P'                         
CL1                   MOVE 'S'       DZJ2S1            
CL1                   UPDATàPLTAR1                     
CL1                   ENDIF

La clé unique du fichier est composée de 4 zones : DZBOCE, DZBMCE, DZBLCE, DZBGDT.

En gros, je cherche la rupture dernière sur les 3 premières zones de la clé, et si le statut est à 'P', je le passe à 'S'.


A l'exécution, le programme plante aussitôt, car au moment de l'update, les données sont bien celles de l'enregistrement en rupture, mais le pointeur interne du fichier est sur l'enregistrement suivant. J'ai donc immédiatement une clé en double générée.

J'ai donc compris pourquoi ça ne marchait pas.
Et pourtant je ne peux me faire à l'idée que le principe soit faux. Il me semble bien que le cycle GAP permet justement de passer outre ces problèmes de ruptures, et que les mises à jours de ce type sont possibles.

Ou alors c'est que je perds la mémoire et qu'alzheimer me guette...

Qu'en pensez-vous ? Correct ou pas correct ?

[Mercure]

La zone DZJ2S1 n'apparaissant pas dans ton programme, je suppose que très probablement tu dois avoir un autre logique pointant sur le même physique qui contient la zone DZJ2S1 en clé pour que tu aies le plantage "clé en double".

Assure-t'en en faisant une simulation avec SQL sur le physique :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Update PHYSIQUE set DZJ2S1 = 'S' where DZJ2S1 = 'P'

et tu verras dans la log du passage le message d'erreur qui t'indiquera sur quel logique tu as la clé en double.

[mutsum1]

non, la seule clé unique du fichier est uniquement constituée des 4 zones DZBOCE, DZBMCE, DZBLCE, DZBGDT.

la zone DZJ2S1 n'est qu'une zone de statut, située en fin de fichier. Elle n'apparaît pas dans la clé.

J'ai débuggué mon programme en me basant sur le N° d'enregistrement donné par le dump, et en faisant un DSPPFM. Je constate que le programme cherche bien à mettre à jour l'enregistrement suivant, et non pas celui correspondant aux données actuellement en mémoire du programme.

En fait, il me donne les données de l'enregistrement 1, mais le pointeur interne est sur l'enregistrement 2. Au moment de l'update, il recopie donc les données du 1 sur le 2, ce qui provoque aussitôt une clé en double.

Ce fonctionnement me paraît aberrant...

[mutsum1]

Bon, j'ai refait un test en simplifiant tout ça pour me concentrer sur l'essentiel :

Si je prends un fichier unique nommé FTEST (aucun logique sur ce fichier) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
A                                      UNIQUE
A          R àTEST                           
A            WBOCE          3                
A            WJ2S1          1                
A          K WBOCE

qui contient les enregistrements suivants:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
WBOCE   WJ2S1
 001      P   
 002      A

et le programme suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
FFTEST   UP  E           K        DISK                 
 *                                                     
IàTEST                                                 
I                                              WBOCE L1
 *                                                     
CL1                   MOVE 'S'       WJ2S1             
CL1                   UPDATàTEST

J'obtiens la même erreur, clé en double immédiate.
Est-ce que ça fait la même chose chez vous ?

[Green Hornet]

oui ça fait pareil mais le pointeur est logiquement fixé sur l'enregistrement pour déterminer la rupture...
de mémoire je n'ai jamais écrit ou vu de programme avec une mise à jour (du fichier lu en primaire) en rupture total, la plupart du temps les mises à jour sont faites dans le cycle détail et parfois selon les besoins dans la rupture détail après avoir mémorisé la clé précédente pour chainer le fichier via un autre logique et le mettre à jour ...

peut être que cette méthode répondre à ton soucis

[mutsum1]

Merci pour cette réponse.

Je suis arrivé à corriger mon problème en faisant la mise à jour sur une autre vue logique.

Mais j'étais plutôt interloqué par un principe que j'étais sûr d'être correct.
J'en étais arrivé à soupçonner un problème suite à la dernière montée de version de l'AS400.

Il faut croire que ce n'est que ma mémoire qui flanche.

Encore merci pour le temps passé.