Parcourir un curseur

Bonjour,
J’aimerais connaître une méthode pour lire tous les rangs d’un curseur sans entrer dans une boucle infinie. C'est à dire quitter la boucle avec P = 0 avant que le fetch atteigne EOF.
Langage : COBOL SQL.
Voilà le code que j'ai essayé mais son exécution a fini par une boucle infinie :
/*******************************************************/
Déclaration d'un curseur nommé "C", le remplir dans l'ordre décroissant, l'ouvrir et puis le parcourir comme suit :
/*******************************************************/

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

EXEC SQL FETCH FIRST FROM C INTO :W END-EXEC R4. IF W = 0 THEN GO TO R43 ELSE IF P < W THEN GO TO R41 ELSE GO TO R42. R41. EXEC SQL FETCH NEXT FROM C INTO :W END-EXEC GO TO R4. R42. COMPUTE P = W. R43. COMPUTE P = 0.

---

Merci d'avance.

Il me semble que tu devrais raisonner programmation structurée :
1 - Ton Fetch dans un Perform in line.
2 - Tu oublies les GO TO (et même les points) et tu poses un EVALUATE avec les When qui vont bien pour tous les cas que tu peux rencontrer et je fais le pari que tu pourras corriger sans difficulté ton problème.
nb. Je sais, en COBOL 1, il n'y avait pas trop le choix et je détestais ce langage. En COBOL II, pouvoir structurer signifie pouvoir poser les condition comme on raisonne. Ca aide.

Citation:

---

Envoyé par SGHAIRI

...
Voilà le code que j'ai essayé mais son exécution a fini par une boucle infinie :

---

Je dirais qu'il manque le test de fin du curseur ...

Par ailleurs c'est du COBOL et DB2 z/OS ?

Citation:

---

Envoyé par Luc Orient

Je dirais qu'il manque le test de fin du curseur ...

Par ailleurs c'est du COBOL et DB2 z/OS ?

---

Bonjour,

Et pourquoi tu n'écrirais pas un truc du style (J'aime pas les GO TO :P )

OPEN toto
FETCH toto

PERFORM UNTIL FIN OR ERREUR
FETCH toto
END-PERFORM

CLOSE toto
?

Pour en rajouter une couche, la méthode que tu utilises est vraiment horrible à maintenir(je sais que c'était à la mode y'a 30 ans, j'en ai même croisé des fanboys, mais c'est à bannir quand même). J'ai eu à faire passer quelques milliers de lignes écrits comme ça à un standard plus lisible, j'en ai ****.

en programmation structurée, sans rien changer(donc en gardant les eventuelles erreurs), ça donnerait :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

01 FLAG-SORTIE-FETCH PIC X(001). 88 SORTIE-FETCH-OUI VALUE 'O'. 88 SORTIE-FETCH-NON VALUE 'N'. (.../...) PERFORM DEBUT-FETCH THRU DEBUT-FETCH-FIN SET SORTIE-FETCH-NON TO TRUE PERFORM TRAITEMENT-FETCH THRU TRAITEMENT-FETCH-FIN UNTIL SORTIE-FETCH-OUI (.../...) DEBUT-FETCH. EXEC SQL FETCH FIRST FROM C INTO :W END-EXEC . DEBUT-FETCH-FIN. EXIT. TRAITEMENT-FETCH. EVALUATE TRUE WHEN W=0 COMPUTE P = 0 SET SORTIE-FETCH-OUI TO TRUE WHEN P<W EXEC SQL FETCH NEXT FROM C INTO :W END-EXEC WHEN OTHER COMPUTE P = W SET SORTIE-FETCH-OUI TO TRUE END-EVALUATE . TRAITEMENT-FETCH-FIN. EXIT.

---

ça, c'est exactement pareil que ton code, sauf que c'est lisible(y'a sans doute moyen de faire mieux, mais bon). J'ai pu faire la transco parce que je n'ai fait que ça pendant 6 mois, mais il m'a fallu ce temps là pour m'habituer à ces archaïsmes à oublier au plus vite. Un non-habitué va vomir en voyant les GO TO Lxy.

Maintenant, ton problème. Me semble que Luc Orient a la réponse : tu ne fermes pas ton curseur. Donc rajouter un CLOSE curseur juste après le PERFORM UNTIL, et ça devrait aller.

EDIT : bonne remarque de ben, tu te trimballes 2 fois exactement le même fetch. Version améliorée :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48

01 FLAG-SORTIE-FETCH PIC X(001). 88 SORTIE-FETCH-OUI VALUE 'O'. 88 SORTIE-FETCH-NON VALUE 'N'. (.../...) PERFORM OPEN-BASE THRU OPEN-BASE-FIN SET SORTIE-FETCH-NON TO TRUE PERFORM TRAITEMENT-FETCH THRU TRAITEMENT-FETCH-FIN UNTIL SORTIE-FETCH-OUI PERFORM CLOSE-BASE THRU CLOSE-BASE-FIN (.../...) TRAITEMENT-FETCH. PERFORM FETCH-BASE THRU FETCH-BASE-FIN EVALUATE TRUE WHEN W=0 COMPUTE P = 0 SET SORTIE-FETCH-OUI TO TRUE WHEN P<W CONTINUE WHEN OTHER COMPUTE P = W SET SORTIE-FETCH-OUI TO TRUE END-EVALUATE . TRAITEMENT-FETCH-FIN. EXIT. (.../...) FETCH-BASE. EXEC SQL FETCH FROM C INTO :W END-EXEC (plus traitement d'erreur, qui inclut :) EVALUATE SQLCODE WHEN ZERO CONTINUE WHEN +100 SET SORTIE-FETCH-OUI TO TRUE WHEN OTHER DISPLAY 'ERREUR MAJEURE SQL : "' SQLCODE '"' CALL ABEND(enfin, un truc qui arrête ton programme, le standard dans ta boite) END-EVALUATE . FETCH-BASE-FIN. EXIT.

---

Je fais pas les OPEN-CLOSE, tu dois savoir faire. Les mettre dans des PERFORM In-line, c'est peut-être overkill, c'est pas obligatoire.

Par contre, en vert, le petit détail qui doit te manquer : si tu n'as pas trouver ton P=0, tu dois quand même sortir.....

(et je suis pas au boulot, je sais plus si c'est SQL-CODE ou SQLCODE.....) - doit y avoir des erreurs de compil, mais ça tu dois savoir faire.

Sinon pour ceux qui travaillent en DB2 V8, il est maintenant possible de faire du multi row fetch, un fetch pour ramener x lignes.

Utilisation fortement conseillée dans le cas de très nombreux fetch.

Pour 100 000 lignes ramenées par paquet de 1000, des gains de 50% cpu ont eté mesuré...

Pour de faibles volumétries (de l'ordre du millier) son utilisation n'est pas justifiée.

Le codage de celui est un peu plus complexe qu'un simple curseur par contre.

Plus d'information sur cette page

Cordialement,

Citation:

---

Envoyé par Cirdeco

Pour 100 000 lignes ramenées par paquet de 1000, des gains de 50% cpu ont eté mesuré...

---

Les DBA du site sur lequel je travaille actuellement préconise de ne pas dépasser 100 occurences en v9. En tout état de cause on obtient effectivement un gain de performance notable.

.