The setWasNull throws if the procedure has not been executed yet.
Embedded handles this. It is not obvious from the Javadoc
that this is a requirement:

(quote from CallableStatement):
"The type of all OUT parameters must be registered prior to executing the stored procedure;
their values are retrieved after execution via the get methods provided here."

I found no verbiage discussing whether it is legal to access an INOUT parameter prior to execution.

BTW, in my small repro, I got an exception on the client (not wrong value as mention in thread; don't know why;
looking at the code it seems there should be an exception, but maybe the some flag is not cleared on
re-execution.

Output from my repro:

Testing with org.apache.derby.jdbc.ClientDriver
XJ088: java.sql.SQLException: Invalid operation: wasNull() called with no data retrieved.
java.sql.SQLException: Invalid operation: wasNull() called with no data retrieved.
at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:95)
at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:362)
at org.apache.derby.client.am.CallableStatement.getInt(CallableStatement.java:322)
at derby2786.Main.doStuff(Main.java:126)
at derby2786.Main.doBothDrivers(Main.java:192)
at derby2786.Main.main(Main.java:211)
Caused by: org.apache.derby.client.am.SqlException: Invalid operation: wasNull() called with no data retrieved.
at org.apache.derby.client.am.CallableStatement.wasNullX(CallableStatement.java:226)
at org.apache.derby.client.am.CallableStatement.getIntX(CallableStatement.java:331)
at org.apache.derby.client.am.CallableStatement.getInt(CallableStatement.java:313)
... 3 more

Testing with org.apache.derby.jdbc.EmbeddedDriver
DUMMYINT alias before returned 6
DUMMYINT alias after returned 22222

Dag H. Wanvik
added a comment - 12/Jun/07 03:55 I had a look at the client code; it does not handle CallableStatement#getXXX()
prior to executing the procedure INOUT parameters:
E.g.
int getIntX(int parameterIndex) throws SqlException
{
super.checkForClosedStatement();
checkGetterPreconditions(parameterIndex);
setWasNull(parameterIndex);
** return wasNullX() ? 0 : singletonRowData_.getInt(parameterIndex);
}
The setWasNull throws if the procedure has not been executed yet.
Embedded handles this. It is not obvious from the Javadoc
that this is a requirement:
(quote from CallableStatement):
"The type of all OUT parameters must be registered prior to executing the stored procedure;
their values are retrieved after execution via the get methods provided here."
I found no verbiage discussing whether it is legal to access an INOUT parameter prior to execution.
BTW, in my small repro, I got an exception on the client (not wrong value as mention in thread; don't know why;
looking at the code it seems there should be an exception, but maybe the some flag is not cleared on
re-execution.
Output from my repro:
Testing with org.apache.derby.jdbc.ClientDriver
XJ088: java.sql.SQLException: Invalid operation: wasNull() called with no data retrieved.
java.sql.SQLException: Invalid operation: wasNull() called with no data retrieved.
at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:95)
at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:362)
at org.apache.derby.client.am.CallableStatement.getInt(CallableStatement.java:322)
at derby2786.Main.doStuff(Main.java:126)
at derby2786.Main.doBothDrivers(Main.java:192)
at derby2786.Main.main(Main.java:211)
Caused by: org.apache.derby.client.am.SqlException: Invalid operation: wasNull() called with no data retrieved.
at org.apache.derby.client.am.CallableStatement.wasNullX(CallableStatement.java:226)
at org.apache.derby.client.am.CallableStatement.getIntX(CallableStatement.java:331)
at org.apache.derby.client.am.CallableStatement.getInt(CallableStatement.java:313)
... 3 more
Testing with org.apache.derby.jdbc.EmbeddedDriver
DUMMYINT alias before returned 6
DUMMYINT alias after returned 22222

but one needs to handle type conversion/checking appropriately as well
(inside the new getInt(Object o) above). The current conversion methods are geared to pick
up data from the query execution result, not the parameter array, so fixing this will
likely require a whole new set of conversion methods.