Version imprimable
Bonjour les forumnautes !
Comment effectuer du sql dynamique via un programme cobol ?
J'ai un fichier en entrée avec des noms de tables DB2 => OK
Je veux acceder à toutes les tables du fichier en entrée par SQL dynamique...
Comment fait-on ? Avez-vous un exemple à me donner ? faut-il mettre des zones précises en linkage ? etc...
Merci pour vos réponses !
Personne pour me répondre ?
Peut-être me suis-je mal fait comprendre ?
Je voudrais effectuer des accès dynamiques à des tables DB2, dans un programme cobol (pour effectuer des count (*))... quelqu'un a-t-il un exemple de programme cobol, utilisant du sql dynamique... j'aimerai savoir quels sont les paramètres à rajouter... en working... en linkage etc...
Merci d'avance pour vos réponses...
En fait, ma question est la suivante : Comment construire une requête dynamique dans un programme Cobol...
Merci pour vos réponses
Bonjour,
Tu trouveras des exemples dans l'Application Programming
and SQL Guide
Version 7
Document Number SC26-9933-04
La difficulté en cobol est de traiter ( si tu t'en sers ) la SQLDA. Il faut créer un programme qui appelle un sous pro pour allouer la SQLDA en linkage.
Alex.
Bonjour,
Tu trouveras des exemples dans l'Application Programming
and SQL Guide
Version 7
Document Number SC26-9933-04
La difficulté en cobol est de traiter ( si tu t'en sers ) la SQLDA. Il faut créer un programme qui appelle un sous pro pour allouer la SQLDA en linkage.
Alex.
Moi, je regarderais là dedans :
Dynamic SQL for fixed-list SELECT statements
Vous êtes vraiment sûr de ça ?Citation:
Envoyé par alex.
Vous pouvez regarder les samples fournis avec le redbook :
Squeezing the Most Out of Dynamic SQL with DB2 for z/OS and OS/390.
Pour les télécharger :
ftp://www.redbooks.ibm.com/redbooks/SG246418
Je pense qu'il faut gérer ça par curseur.
et ça devrait aller.Code:
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
28Working-Storage Section. 01 Compteur pic s9(7) Comp-3. 01 MyString pic x(80). Linkage Section. Exec sql include sqlca End-Exec. Puis, dans la PD, itérer sur le fichier qui contient le nom des tables, puis préparer et exécuter l'instruction de comptage de chaque table via une lecture par curseur. * Concaténer en ZT l'intruction de comptage SQL avec le nom de la table: String 'Select Count(*) From ' Delimited By Size ' ' Delimited By Size NomTable Delimited By ' ' Into MyString. Exec sql Prepare SqlStm From :MyString End-exec. Exec sql Declare c1 cursor For SqlStm End-exec. Exec sql Open c1 End-exec. Exec sql Fetch c1 Into :Compteur End-exec. Exec sql Close c1 End-exec. Boucle sur lecture fichier
Nous tenir au courant, svp.
Pour moi, l'exemple donné par Mercure me semble pas mal ...
Mais encore une fois pourquoi mettre la SQLCA en LINKAGE SECTION ?
Luc,
Parce qu'il me semble bien, sauf erreur de ma part, que la zone de communication de SQL (SQLCA) n'est pas automatiquement générée par le compilateur Cobol sur toutes les plates-formes qui supportent à la fois Cobol et DB2, par ex. sur iSeries-i5-AS/400. Or, ce dernier en a besoin pour compiler correctement les instructions Cobol que SQL génère à partir des instructions source contenues entre Exec sql et End-exec.Code:... pourquoi mettre la SQLCA en LINKAGE SECTION ?
Me trompè-je ?
Petite précision :Citation:
Envoyé par Mercure
J'ai supposé que l'environnement dont il était question ici était le z/OS et par conséquent toutes les remarques que j'ai pu faire ou que je vais faire ne s'appliquent qu'à celui-ci ...
Je suis tout à fait d'accord qu'il faut inclure dans un programme COBOL DB2 la SQLCA pour pouvoir programmer de manière correcte ...
Ce qui me surprend un peu c'est de positionner cette déclaration dans la LINKAGE SECTION du programme COBOL ...
FYI.
En fait, sur iSeries-i5-AS/400-etc, lorsqu'on utilise le compilateur "original" (OPM), on peut inclure la SQLCA soit en Working Storage Section, soit en Linkage Section, au choix. L'inclusion de la SQLCA peut toutefois être omise si on déclare explicitement les variables SQLCODE et/ou SQLSTATE. Dans ce dernier cas, la zone de communication de SQL (SQLCA) sera généré par le compilateur et les 2 variables seront renommées. Cependant, dans les récents modèles ILE du compilateur Cobol, la SQLCA est effectivement systématiquement générée par ce compilateur si elle n'est pas explicitement déclarée en WSS ou LS.
Qu'on se le dise ! :?
C'est différent en z/OS clairement ...Citation:
Envoyé par Mercure
Bon maintenant, je pense que l'auteur initial du sujet doit nous préciser dans quel environnement il travaille et nous dire aussi où il en est de ses propres essais ..
Je pense qu'il a maintenant suffisamment d'éléments pour avancer par lui-même ...
Bonjour,
Pour la question sur le SQLDA de Luc, cela ne concerne que les varying list select. Comme on ne connait pas à l'avance le nombre de colonnes, on ne peut pas définir une taille fixe de SQLDA. Cela nécessite de faire une allocation par la suite et en cobol, le seul moyen est de faire un call.
Tu peux regarder dans l'Application Programming Guide
APPENDIX1.4.1 Sample COBOL dynamic SQL program.
APPENDIX1.4.1.2 Storage allocation
COBOL does not provide a means to allocate main storage within a program. You can achieve the same end by having an initial program which
allocates the storage, and then calls a second program that manipulates the pointer. (COBOL does not permit you to directly manipulate the
pointer because errors and abends are likely to occur.)
The initial program is extremely simple. It includes a working storage section that allocates the maximum amount of storage needed. This program
then calls the second program, passing the area or areas on the CALL statement. The second program defines the area in the linkage section and
can then use pointers within the area.
If you need to allocate parts of storage, the best method is to use indexes or subscripts. You can use subscripts for arithmetic and comparison
operations.
Alex.
Je pense qu'il y a eu confusion entre SQLCA et SQLDA. Il faut dire qu'il y a de quoi avec des noms pareils !
Mais ce que dit Alex sur la SQLDA est exact dans la mesure où, pour gérer des zones de fichier via la SQLDA, cela demande pas mal d'efforts et de lignes de programmation, que ce soit en Cobol ou dans un autre langage d'ailleurs.