Discussion :

[Yan302]

Bonjour à tous,

J'ai une erreur sql 818 et je n'arrive pas à comprendre pourquoi.

Voilà la séquence des commandes que j'exécute :

("cl" est le compilateur de Microsoft Visual Studio)

db2 connect to sample

db2 prep gdk_PERSON.sqc bindfile
db2 bind gdk_PERSON.bnd
cl -Zi -LD /DDKTARGET_NT -I. -I../runtime -I/include -c gdk_PERSON.c

db2 prep gdk_PERSONZ.sqc bindfile
db2 bind gdk_PERSONZ.bnd
cl -Zi -LD /DDKTARGET_NT -I. -I../runtime -I/include -c gdk_PERSONZ.c

db2 prep gdk_POLY.sqc bindfile
db2 bind gdk_POLY.bnd
cl -Zi -LD /DDKTARGET_NT -I. -I../runtime -I/include -c gdk_POLY.c

db2 prep gdk_PZZY.sqc bindfile
db2 bind gdk_PZZY.bnd
cl -Zi -LD /DDKTARGET_NT -I. -I../runtime -I/include -c gdk_PZZY.c

db2 prep gdk_tables.sqc bindfile
db2 bind gdk_tables.bnd
cl -Zi -LD /DDKTARGET_NT -I. -I../runtime -I/include -c gdk_tables.c

lib /OUT:gdk.lib gdk_PERSON.obj gdk_PERSONZ.obj gdk_POLY.obj gdk_PZZY.obj gdk_tables.obj

cl -Zi -LD /DDKTARGET_NT /MD /Fedbntry.dll ../runtime/dk_dllentry.obj gen/runtime/gdk.lib ../lib/datakom.lib "C:\Program Files\IBM\SQLLIB\lib\db2api.lib"(cela crée une dll appelé dbntry.dll)

Ensuite, j'ai un programme COBOL (compilé avec les produits microfocus) qui utilise cette dll pour faire les accès à la base de données. Cette DB contient 4 tables : PERSON, PERSONZ, POLY and PZZY).

Si dans mon programme COBOL j'exécute une commande sur la table PERSON, je reçois une sqlerror 818 mais si j'exécute la même commande sur la table PERSONZ, cela fonctionne parfaitement.

I'ai trouvé que cette erreur apparaissait lorsque les timestamps généré par le précompilateur et le "binder" n'était pas les même, j'ai donc essayé de re-precompilé/re-bindé/re-compilé/re-linké mais seulement les références à PERSON :

db2 prep gdk_PERSON.sqc bindfile
db2 bind gdk_PERSON.bnd
cl -Zi -LD /DDKTARGET_NT -I. -I../runtime -I/include -c gdk_PERSON.c
lib /OUT:gdk.lib gdk_PERSON.obj gdk_PERSONZ.obj gdk_POLY.obj gdk_PZZY.obj gdk_tables.obj
cl -Zi -LD /DDKTARGET_NT /MD /Fedbntry.dll ../runtime/dk_dllentry.obj gen/runtime/gdk.lib ../lib/datakom.lib "C:\Program Files\IBM\SQLLIB\lib\db2api.lib"

Le résultat a été que la même requête dans le programme COBOL fonctionne maintenant parfaitement sur PERSON mais plus sur PERSONZ.

Je ne comprends vraiment pas le problème... Est-ce que quelqu'un remarque une bizarrerie dans ma séquence de commande ? Quelqu'un aurait une idée pour résoudre ce problème ?

Toute idée ou aide est la bienvenue !

Merci d'avance,

Yan

[wlassout]

il faudrait pas pre-compiler et compiler le tout sinon les timestamp du dbrm et du programme seront en déphasage ?

[Yan302]

c'est à dire ?

[wlassout]

I'ai trouvé que cette erreur apparaissait lorsque les timestamps généré par le précompilateur et le "binder" n'était pas les même, j'ai donc essayé de re-precompilé/re-bindé/re-compilé/re-linké mais seulement les références à PERSON :


Yan

en clair pourquoi seulement les "références" à PERSON et pas pour toutes les "références" comme cela tout le monde à le même timestamp ?

je ne connais pas bien cette techno mais ne faut il pas que tous les accès en base aient le même timestamp pour que le programme cobol puisse fonctionner ?

[Yan302]

en clair pourquoi seulement les "références" à PERSON et pas pour toutes les "références" comme cela tout le monde à le même timestamp ?

je ne connais pas bien cette techno mais ne faut il pas que tous les accès en base aient le même timestamp pour que le programme cobol puisse fonctionner ?

Si je les fais toutes, cela reviens à la séquence que j'ai posté en premier non ? Et donc le même problème.

[wlassout]

la base qui est interrogée est en quelle version et quelle plate-forme ?


en fait mes questions sont aussi pour comprendre comment ça marche : pourquoi un fichier de bind par table et pas un pour tous les accès contenus dans le programme ?

et ne faudrait il pas avoir comme séquence précompile/compile/link et enfin le bind ?

[Yan302]

wlassout,

tout d'abord merci pour tes réponses et ton aide !

Il s'agit de la version 9.5 qui tourne sous Win XP.

Bien en fait il y a un fichier par table car chaque fichier implémente dans méthodes en C telles que select, insert, delete,... qui joue l'interface avec la DB. Tout ce code est généré. En fait, chaque "type" de requete SQL est implémenté dans ces fichiers.

db2 bind ne permet de prendre en paramètre qu'un seul fichier DBRM donc je ne vois pas comment je pourrais faire autrement que 4 bind distincts ?

Pour ce qui est de l'ordre précompile/compile/link/bind si j'ai bien tout compris le fichier .bnd qui est généré lors de la précompilation n'est ni modifié par la compile ni par le "link" donc faire le bind après la précompilation ou après le link ne devrait rien changer ; je me trompe ?

[wlassout]

je n'affirmerais pas que tu te trompes ... mais ça ne me semble pas logique comme ordre de traitement. (sauf erreur de ma part sur Z/os quand on compile un cobol les steps sont pre-compile/ compile/link et bind dans cet ordre)

alors maintenant si ta méthode est la bonne tu as peut etre un problème d'agent qui reste en mémoire dans db2.

pour le savoir il faudrait regardé si le paramètre Keepfenced est à on ou off en faisant un db2 get dbm cfg si il est à on il faudrait essayé de le passer à off