Re: 8.1.6 -> 8.1.7 upgrade & loadjava

Tarik wrote:

> 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

Thanks.

Daniel Morgan Received on Fri May 10 2002 - 13:24:01 CDT