What can cause the SQL Server JDBC error 'The value is not set for the parameter number 0' for an output parameter access?

Question

I have some Java code that accesses SQL Server 2005 which looks something like this:

CallableStatement cstmt = ...;
... // Set input parameters
cstmt.registerOutParameter(11, Types.INTEGER);
cstmt.execute();
int out = cstmt.getInt(11);

And the following exception is thrown from the last line:

com.microsoft.sqlserver.jdbc.SQLServerException: The value is not set 
     for the parameter number 0.
   at com.microsoft.sqlserver.jdbc.SQLServerException.
     makeFromDriverError(Unknown Source)
   at com.microsoft.sqlserver.jdbc.SQLServerCallableStatement.
     skipOutParameters(Unknown Source)
   at com.microsoft.sqlserver.jdbc.SQLServerCallableStatement.
     getOutParameter(Unknown Source)
   at com.microsoft.sqlserver.jdbc.SQLServerCallableStatement.
     getterGetParam(Unknown Source)
   at com.microsoft.sqlserver.jdbc.SQLServerCallableStatement.
     getInt(Unknown Source)
   at org.jboss.resource.adapter.jdbc.WrappedCallableStatement.
     getInt(WrappedCallableStatement.java:192)

The stored procedure being called looks something like this:

CREATE PROCEDURE dbo.stored_proc ( -- 10 input parameters
                                 , @out_param INT OUTPUT) AS

-- Variable declarations 

SET @out_param = 0

-- Do processing...

SET @out_param = 1

Since the output parameter is set to zero on entry to the stored procedure, under what circumstances could the value not be set? Or am I misinterpreting the error message?

This error is reproducible with:

• SQL Server JDBC Driver 1.2
• SQL Server 2005 (64-bit) service pack 2
• SQL Server 2005 (64-bit) service pack 3

Update: It seems to be occuring as a result of the -- Do processing... part of the stored procedure. Removing this eliminates the error. There's too much code to reproduce here, what I'd like is some pointers to possible causes to narrow down likely candidates.

Update: Injecting errors (e.g. divide by zero) into the -- Do processing... part of the stored procedure does not cause this exception to be thrown (instead, as expected, the execute() call fails with an appropriate error message).

Update: Decompiling the com.microsoft.sqlserver.jdbc.SQLServerCallableStatement class suggests that 'parameter number 0' is the stored procedure return value.

Update: I have been unable to reproduce this by calling the stored procedure directly through Management Studio.

Update: The ultimate cause of this error seems to be a deadlock in the stored procedure. Usually, however, deadlocks cause the execute() call to fail with a SQLException wrapping SQL Server error code 1205...

Answer 1

on your parameters, are you just declaring them or are you setting them to a default value? try setting them to a default value of null or something and see if you still get the error.

sql server doesn't like it if you have a parameter not set to a default value and you don't pass a value to it when you exec the stored procedure.

Answer 2

Are you registering the output parameters? According the the docs "All OUT parameters must be registered before a stored procedure is executed."

Answer 3

There are a couple things that come to mind:

1. You haven't got a RETURN x (where x is an INT representing the outcome of processing, 0 = success, anything else represent a warning or an error).
2. Your client code doesn't assign a parameter for the return value in addition to your output parameter.

Hope this helps,

Bill

Answer 4

Decompiling the com.microsoft.sqlserver.jdbc.SQLServerCallableStatement class suggests that 'parameter number 0' is the stored procedure return value.

Thats correct. If your stored procedure definition has 11 input/output parameters, you actually need to define 12 in your calling code. Parameter 0 is the return code.

For example with a SP with one input and one output parameter, in SSMS you run this:

DECLARE @ReturnValue INT
DECLARE @P1 INT, @P2 INT

EXEC @ReturnValue= YourSP(@P1,@P2 OUTPUT)

You actually have three parameters to deal with here, not two.

Answer 5

In case anyone still getting this problem on SQL server 2008.

I had the same problem on an update statement with trying to set a Timestamp for a DateTime field. The offending field was in a where clause at a different index from the reported one.