I did not follow your earlier posts so forgive me if this has already been
said.
In my experience, which is with DB2 V7.2 and earlier versions, the key
factor in getting fenced stored procedures to refresh themselves correctly
is to set KEEPDARI to NO. You can do this via:
db2 upd dbm cfg using keepdari no
KEEPDARI is a performance setting that should normally be set to YES for a
production environment but should almost certainly be set to NO for a
development environment. Otherwise, you get the sorts of problems you are
having.
As I said, I haven't used DB2 V8 yet so this advice may not be applicable
any longer but it certainly made a big difference in V7.2.
There are other things that can cause stored procedures to have refresh
issues but KEEPDARI is the biggest one in my experience. However, if you
have KEEPDARI set appropriately, there are two other things you should
explore:
1) If you are hand-coding your procedures - as opposed to using the Stored
Procedure Builder/Development Center - your program preparation procedures
may not be correct. You may be compiling the latest version of your program
but your preparation procedures may be putting an older version of the
..class file in your SQLLIB\FUNCTION \JAR\<schema> directory.
2) You may have *both* a .class file and a .jar containing the same program
in your SQLLIB\
FUNCTION\JAR\<s chema>\ directory. In this case, DB2 will always use the
..class file in preference to your .jar, even if the .class file is an older
version.
I've managed to make all three of these mistakes at one point or another so
I understand your frustration with the procedures not refreshing properly.
However, if you make sure that KEEPDARI is NO in a development environment
and verify that your preparation procedures are storing the current version
of the .class file in the SQLLIB\FUNCTION \JAR\<schema> directory, your
problem with refreshing classes *should* go away.
Rhino
"Raquel" <ra************ ****@yahoo.com> wrote in message
news:9a******** *************** ***@posting.goo gle.com...
UDB PE 8.1 on Win XP.
ok, this function caused a lot of grief today. My stored procedures
are java stored procedures, all FENCED and directly placed in
\sqllib\functio n directory (not built into JAR files).
While the manuals state that SQLJ.REFRESH_CL ASSES() only refreshes the
routines built into JAR files, I have been successfully refreshing my
JDBC stored procedures with this function.
A couple of days back, I started developing SQLJ stored procedures and
it took me a long while to figure out that all the strange errors I
was receiving while attempting to run the SQLJ stored procedures
(messages like arguments not being compatible etc.) were because
SQLJ.REFRESH_CL ASSES() was NOT refreshing my SQLJ stored procedures in
\sqllib\functio n. I had to stop and start the database manager
everytime I changed and recompiled a stored procedure. This solved the
problem.
KEEPFENCED in dbm config. file is set to YES (default).
Anyway, so my question is: Is someone on the list aware of what the
deal with SQLJ.REFRESH_CL ASSES() is? Why does it work with JDBC
procedures and not with SQLJ procedures. Actually, per the manual, it
should work *only* for stored procedures that are built into JAR
files. Since my JDBC stored procedures are not built into JAR files,
SQLJ.REFRESH_CL ASSES() should not have worked even with JDBC.
What are your experiences in this regard.
TIA
Raquel.
