8.1.6 -> 8.1.7 upgrade & loadjava

Hi

Thought I'd share this one with you having spent most of the afternoon working out what was going on:

I upgraded my database from 8.1.6.0.0 to 8.1.7.0.0 last week and found that one of my Java stored procedures no longer worked. The PL/SQL wrapper function, though, was still showing it as successfully compiled.

No problem I thought, I'll just reload it and it'll recompile on the way in & everything'll work again.

However what I got was this from the loadjava utility:

        C:\Classes>loadjava -u <username>/<password>@<service> -v -r hex2real.java

	initialization complete
	loading  : hex2real
	creating : hex2real
	Error while creating hex2real
	    ORA-29533: attempt to overwrite class or resource hex2real while
defining or
	 compiling <username>.hex2real

	resolver :
	resolving: hex2real
	Error while resolving class hex2real
	    ORA-04043: object hex2real does not exist

	loadjava: 2 errors

	C:\Classes>
	

I also tried it with the -f (force) option and still got the same message.

According to the the Errors book it says:

ORA-29533 attempt to overwrite class or resource string while defining or compiling string.string

     Cause: A class or resource defined by a SQLJ source conflicted with an existing object.

     Action: Remove existing object, or modify SQLJ source.

but when I tried to remove the class I got:

        C:\Classes>dropjava -u <username>/<password>@<service> -v hex2real.java

	dropping source  : hex2real
	ORA-04043: object hex2real does not exist


	C:\Classes>

The Java manual has this to say on loadjava:

        "You can load either a particular Java .class file or its .java file, but not both.

        JServer tracks whether you loaded a class file or a source file. If you wish to update the class, you must load the same type of file that you originally loaded. If you wish to update the other type, you must drop the first before loading the second. For example, if you loaded x.java as the source for class y, to load x.class, you must first drop x.java.

        You cannot define the same class within two different schema objects within the same schema. For example, suppose x.java defines class y and you want to move the definition of y to z.java. If x.java has already been loaded, loadjava rejects any attempt to load z.java
(which also defines y). Instead, do either of the following:

        Drop x.java, load z.java (which defines y), then load the new x.java
(which does not define y).

        Load the new x.java (which does not define y), then load z.java
(which defines y). "

which I found completely ambiguous! What I actually finally got to work was this:

	dropjava -u <username>/<password>@<service> -v hex2real.CLASS
	(my capitals)
	

and I could then go and happily load up the source file again with the resolver, and run my stored procedure properly.

So the moral is, even though I loaded the original as source code, because I chose to use the -resolve option you must drop the compiled version first in order to reload source code again! Phew!

Tarik Received on Fri May 10 2002 - 11:29:05 CDT