SQL ERRORCODE 818

Version imprimable

09/02/2009, 13h32
Yan302

SQL ERRORCODE 818

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
09/02/2009, 14h19
wlassout

il faudrait pas pre-compiler et compiler le tout sinon les timestamp du dbrm et du programme seront en déphasage ?
09/02/2009, 14h23
Yan302

c'est à dire ?
09/02/2009, 14h34
wlassout

Citation:

Envoyé par Yan302

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 ?
09/02/2009, 14h36
Yan302

Citation:

Envoyé par wlassout

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.
09/02/2009, 14h55
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 ?
09/02/2009, 15h03
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 ?
09/02/2009, 15h13
wlassout

je n'affirmerais pas que tu te trompes :D ... 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
09/02/2009, 15h21
Yan302

merci encore pour ton aide !

J'ai déplacé le bind en fin de chaîne mais le résultat est le même.

Keepfenced était à YES, je l'ai passé à NO ; mais mon problème est toujours là.
09/02/2009, 15h29
wlassout

as tu essayé de refaire un bind de ton client pour être sur que ça ne vient pas de là ?

db2 bind "%DB2PATH%\bnd\@db2cli.lst" blocking all grant public

et un arrêt relance de ton client et / ou de l'instance (pour la prise en compte du keepfenced off)?
09/02/2009, 15h34
Yan302

fait les deux, ca ne change rien :cry:
10/02/2009, 00h04
alex.

Citation:

A modified source file is produced, which contains host language equivalents to the SQL statements. By default, a package is created in the database to which a connection has been established. The name of the package is the same as the file name (minus the extension and folded to uppercase), up to a maximum of 8 characters.

gdk_PERS(ON) = gdk_PERS(ONZ)

Tu écrases l'un avec l'autre peut-être ?
10/02/2009, 09h49
wlassout

8O8O
10/02/2009, 10h39
Yan302

Citation:

Envoyé par alex.

gdk_PERS(ON) = gdk_PERS(ONZ)

Tu écrases l'un avec l'autre peut-être ?

oh tu as peut-être bien raison Alex ! Quand je liste les packages je n'en ai que 4 :
GDK_PERS
GDK_POLY
GDK_PZZY
GDK_TABL

alors que je devrais en avoir 5

J'essaye de changer ça et je vous tiens au courant !

Merci pour ta réponse Alex ;-)
10/02/2009, 11h20
Yan302

et bien voilà, c'est testé et le problème était en effet cela.

Merci à vous deux pour votre aide qui m'a été d'un grand secours !

++
10/02/2009, 11h31
wlassout

:D ben c'est beau la technique ....