Don Chamberlin's "Complete Guide to DB2 UDB" says:
<<A Java stored procedure can return an error code and message to the
client by throwing an exception of type SQLException, which is supported
by the JDBC class library...
...If a Java stored procedure throws an exception that is not an
SQLException, the client program receives SQLCODE -4302 and SQLSTATE
38501.>>
The DB2 UDB v5.2 help files seem to bear this out:
<<Any exception returned from the stored procedure is caught by the
database and returned to the caller with SQLCODE -4302, SQLSTATE 38501.
A JDBC SQLException or SQLWarning is handled specially and passes its
own SQLCODE, SQLSTATE etc. to the calling application verbatim.>>
Yet, when my stored procedure throws an SQLException, it is the -4302
that is returned to the calling program, not the original error code.
<<
In test procedure, catching SQL exception...
-4302
38501
[IBM][CLI Driver][DB2/Windows 95] SQL4302N Java stored procedure or
user-define
d function "JEREMY .SET_PSIST_DATE", specific name "SQL991102225014010"
aborted
with an exception "[IBM][CLI Driver][DB2/Wind". SQLSTATE=38501
>>
The db2diag.log shows the original error thrown by the stored procedure:
<<
1999-11-10-00.08.49.090000 Instance:DB2 Node:000
PID:-1482-4099539(db2dari.exe) TID:-4099539 Appid:
BSU Java support sqlejCallSTP_dll Probe:120
java.sql.SQLException: [IBM][CLI Driver][DB2/Windows 95] SQL0100W No
row was found for FETCH, UPDATE or DELETE; or the result of a query is
an empty table. SQLSTATE=02000
Error occurred in the persistent date UPDATE...
ORG_ID=HFAX
SYS_CODE=UDT
CTEXT_CODE=LIVE
at UDT.StoredProcedures.SqlPersistentDate.setDate(SqlPersistentD
ate.java:220)
>>
I would expect the original SQLException to be thrown back to the
calling program. Is this is DB2 bug, or have I misunderstood something?
--
Jeremy Rickard
--
Jeremy Rickard
(To email, change "SPAM" to "jbdr" in address.)