Discussion :

[Miketheglide]

Bonjour

J'ai un problème un peu pointu (enfin pour moi en tous les cas).

J'ai une série de lignes qui sortent d'un FETCH d'une requete SQL que je veux comparer a une table interne.
Voila le cas :

Soit A la première table
Soit B la seconde table

je dois écrire tous les éléments qui sont dans A et B, mais aussi ceux qui sonu uniquement dans A et ceux qui sont uniquement dans B (en SQL cela revient a faire un FULL OUTER JOIN) mais en Cobol ??? j'essaye de voir la fonction SEARCH mais je ne sais pas trop.

Merci pour votre aide.

[escartefigue]

Bonjour,

Soit votre table interne est elle aussi issue d'une requete SQL, auquel cas le plus simple est de construire une requete de type full outer join, et d'analyser les nulls pour savoir qui correspond ou non

Soit ce n'est pas le cas, alors le plus simple est de trier les 2 résultats et de faire comme pour un appareillage de fichier, selon la méthode de comparaison des clefs (clef A < clef B, clef A = clef B et clef A > clef B avec lecture du fichier 1/et ou 2 selon le cas)

Si vous travaillez sur de très gros volumes, vous pouvez aussi décharger votre table DB2 et trier le résultat, mettre votre table cobol dans un fichier, et faire un appareillage par ICETOOL

[Miketheglide]

Merci pour la reponse.
J'ai commence a faire ca mais j'ai encore une petite question.
Dans mon FETCH je dois faire une rupture sur un numéro spécifique (ici c'est le numéro de banque).
En fait je lis mon Curseur jusqu’à changement de banque et je charge au fur et a mesure une table interne indexée. Chaque fois que je change de banque je commence la comparaison avec l'autre table interne.

Comment gérer cette rupture sur un FETCH ?

[escartefigue]

Il n'y a aucun impact coté SQL, sauf à bien sur s'assurer que votre curseur est bien trié sur le code banque
C'est au niveau du code COBOL qu'il faudra gérer la rupture de façon classique, le plus simple est sans doute de déverser la table à traiter dans une zone de working à rupture sur le code banque
De façon à comparer toujours la même table (cette WSS) avec les valeurs issues du curseur.

Puisque votre traitement ne fait que de la lecture, pensez à mettre la clause "FOR FETCH ONLY" dans votre curseur
Et puisque vous ferez de la lecture en masse, pensez aussi à utiliser le "ROWSET POSITIONNING"
Si la table lue est très grosse, centaines de millions ou milliards de lignes, et que les normes de prod vous y autorisent, il serait préférable de traiter un fichier d'unload séquentiellement plutôt que de passer par un curseur : pas de contention avec les autres applis, isolation implicite et temps de traitement optimisé

[Miketheglide]

merci. c'est ce que je vais essayer de faire :

1) Lecture de ma table avec deversation dans une table interne jusqu'a rupture du code banque
2) Comparaison du résultat obtenu avec l'autre table interne (en faisant une boucle) : si code banque egal, si plus petit, si plus grand
3) Retour a la lecture de la table pour refaire une rupture sur un nouveau code banque.

C'est bien ca ?

[escartefigue]

Oui, c'est le principe d'un appareillage de fichier, sauf que l'un des deux fichiers est une table mémoire, mais ca ne change rien au principe

[alotfi]

Bonjour

J'ai un problème un peu pointu (enfin pour moi en tous les cas).

J'ai une série de lignes qui sortent d'un FETCH d'une requete SQL que je veux comparer a une table interne.
Voila le cas :

Soit A la première table
Soit B la seconde table

je dois écrire tous les éléments qui sont dans A et B, mais aussi ceux qui sonu uniquement dans A et ceux qui sont uniquement dans B (en SQL cela revient a faire un FULL OUTER JOIN) mais en Cobol ??? j'essaye de voir la fonction SEARCH mais je ne sais pas trop.

Merci pour votre aide.

Bonjour,

J'arrive un peu tard, mais j'ai une idée qui pourrait être utile à ceux qui sont intéressés par ce sujet.
Puisqu'il s'agit d'écrire un fichier (si j'ai bien compris) pourquoi ne pas écrire toutes les données des 2 tableaux dans un même fichier séquentiel, puis dans le step suivant de procéder à tri en éliminant les doublons.
L'avantage de cette solution, si elle possible dans votre cas est double, puisqu'il n'y a pas d'algo d'appareillage à coder et en terme de temps de traitement DFSORT est nettement plus rapide.

[escartefigue]

Cette solution consiste à multiplier les i/o par 2, l'espace disque également
Écrire un appareillage de fichiers ne pose aucun problème a qui l'a déjà fait au moins une fois
Ceux qui ne l'ont jamais fait trouveront facilement un exemple en cherchant un peu