By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,557 Members | 1,068 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,557 IT Pros & Developers. It's quick & easy.

Regarding install_jar functioning

P: n/a
Hi,
Could any one please shed some light as to how an jar whose copy
has been deleted from the SQLLIB\FUNCTIONs\JAR\<schema> still be
referred to from our projects?
Even after installing a fresh copy of the jar, the old copy is still
being referenced.

May 3 '06 #1
Share this Question
Share on Google+
4 Replies


P: n/a
"The Java class files that you use to implement a routine must reside
in either a JAR file you have installed in the database, or in the
correct CLASSPATH for your operating system. The DB2 classloader
searches the classes and JAR files in the CLASSPATH and will pick up
the first class it encounters with the specified name."

Are you sure that there are no simillar class in some other jar in
CLASS path or path registered with database ?

May 3 '06 #2

P: n/a

"annhere" <an*****************@gmail.com> wrote in message
news:11**********************@i39g2000cwa.googlegr oups.com...
Hi,
Could any one please shed some light as to how an jar whose copy
has been deleted from the SQLLIB\FUNCTIONs\JAR\<schema> still be
referred to from our projects?
Even after installing a fresh copy of the jar, the old copy is still
being referenced.


This sounds like a problem I had a while back when I was writing some course
materials about stored procedures for DB2 Version 7. I believe the same
problem occurs with respect to functions.

I did some research and experimentation on this problem at the time,
including some Google searches of the archives of this newsgroup, and wrote
some documentation about what I learned. I _think_ this documentation should
still be valid in DB2 Version 8. Here is what I wrote:

----------------------------------------------------------------------------------------------------------------
Stored Procedure Won't Refresh

This is the situation where the stored procedure is prepared without any
error messages arising but the stored procedure that is executed is clearly
an older version of the desired procedure, not the current version.

The most common reason for this is that the KEEPDARI setting in the database
manager configuration is 'YES'. A KEEPDARI setting of 'YES' is appropriate
for a production environment because it improves performance by cacheing
stored procedures. However, KEEPDARI should be 'NO' in a development or
training environment.

To determine the value of the KEEPDARI setting, follow these steps:

Launch a DB2 Command Window and execute the following command at the prompt:
db2 get dbm cfg | more

Scroll down through the result by pressing your space bar until you see a
line that starts "Keep DARI process (KEEPDARI) = ".
If the value of the KEEPDARI value is not appropriate for your environment,
you need to change it and then stop DB2 and restart it. This can be
accomplished by entering each of the following commands at the DB2 Command
Window prompt in this order:

db2 update dbm cfg using keepdari no (or 'db2 update dbm cfg using keepdari
yes' if you want to make the KEEPDARI value 'yes')

db2 terminate

db2 force application all

db2stop

db2start

Each of those commands should execute without displaying any error messages.

If the value of KEEPDARI was already 'NO' when the problem occurred, the
KEEPDARI setting was _NOT_ the reason that the stored procedure won't
refresh.

In that case, try entering this command at a DB2 Command Window: db2
terminate. Then try the stored procedure again.

If that doesn't work, execute the following command in a DB2 Command Window:
db2 call sqlj.refresh_classes(). Try the stored procedure again.

If that still doesn't work, execute the following commands in a DB2 Command
window in the sequence shown:

db2 force application all

db2stop

db2start

Then try the stored procedure again.

---

The other common reason for encountering this problem is that the
preparation procedures contain an error. For example, if the Java compile
step writes the class files to directory FOO and the jar step gathers the
class files from directory BAR, the code that is being compiled is different
from the code that is being jarred. In this case, no amount of recompiling
will refresh the code and the other measures discussed above will be
ineffective: the preparation procedures need to be revised so that the code
which is compiled is also the code which is jarred and installed in DB2.

----------------------------------------------------------------------------------------------------------------

--
Rhino
May 3 '06 #3

P: n/a
Hi ... thanx a lot for your suggestions... It has worked. As suggested
it was look up a jar of the same nae in another folder.

Because of some error, 2 functions of the same name 'A' had formed in 2
schemas.
So jars were formed in 2 schemas too ... one in SQLLIB\FUNCTIONS\JARS\S
& SQLLIB\FUNCTIONS\JARS\Y. We required the jar in Schema 'Y' . However
it was constantly referring to the jar in 'S' . After physically
deleting this jar & then running the script again the problem was
solved.

May 3 '06 #4

P: n/a

"annhere" <an*****************@gmail.com> wrote in message
news:11**********************@i39g2000cwa.googlegr oups.com...
Hi ... thanx a lot for your suggestions... It has worked. As suggested
it was look up a jar of the same nae in another folder.

Because of some error, 2 functions of the same name 'A' had formed in 2
schemas.
So jars were formed in 2 schemas too ... one in SQLLIB\FUNCTIONS\JARS\S
& SQLLIB\FUNCTIONS\JARS\Y. We required the jar in Schema 'Y' . However
it was constantly referring to the jar in 'S' . After physically
deleting this jar & then running the script again the problem was
solved.

Excellent! I'm glad to hear that you solved your problem :-)

--
Rhino
May 3 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.