Что может вызвать ошибку JDBC SQL Server «Значение не задано для параметра номер 0» для доступа к выходному параметру?

У меня есть код Java, который обращается к SQL Server 2005, который выглядит примерно так:

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

И следующее исключение выбрасывается из последней строки:

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)

Вызываемая хранимая процедура выглядит примерно так:

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

Поскольку выходной параметр устанавливается на ноль при входе в хранимую процедуру, при каких обстоятельствах это значение не может быть установлено? Или я неверно истолковал сообщение об ошибке?

Эта ошибка воспроизводится с помощью:

  • Драйвер JDBC для SQL Server 1.2
  • Пакет обновления 2 для SQL Server 2005 (64-разрядная версия)
  • SQL Server 2005 (64-разрядная версия) с пакетом обновления 3

Обновление. Похоже, это происходит из-за -- Do processing... части хранимой процедуры. Удаление этого устраняет ошибку. Здесь слишком много кода, чтобы воспроизвести его, я бы хотел несколько указателей на возможные причины, чтобы сузить круг возможных кандидатов.

Обновление: добавление ошибок (например, деление на ноль) в -- Do processing... часть хранимой процедуры не вызывает возникновение этого исключения (вместо этого, как и ожидалось, вызов execute() завершается ошибкой с соответствующим сообщением об ошибке).

Обновление: декомпиляция класса com.microsoft.sqlserver.jdbc.SQLServerCallableStatement предполагает, что «параметр номер 0» является возвращаемым значением хранимой процедуры.

Обновление: мне не удалось воспроизвести это, вызвав хранимую процедуру напрямую через Management Studio.

Обновление. По всей видимости, основной причиной этой ошибки является тупиковая ситуация в хранимой процедуре. Однако обычно тупиковые ситуации вызывают сбой execute() вызова с SQLException кодом ошибки SQL Server 1205 ...


sql-server stored-procedures jdbc mssql-jdbc
person Community    schedule 13.05.2009    source источник

Ответы (5)


arrow_upward
0
arrow_downward

по вашим параметрам, вы просто объявляете их или устанавливаете для них значение по умолчанию? попробуйте установить для них значение по умолчанию, равное нулю или что-то в этом роде, и посмотрите, по-прежнему ли вы получаете ошибку.

sql-серверу не нравится, если у вас есть параметр, для которого не установлено значение по умолчанию, и вы не передаете ему значение при выполнении хранимой процедуры.

person DForck42    schedule 13.05.2009
comment
Верно ли это и для параметров ВЫХОДА? - person Matthew Murdoch; 13.05.2009
comment
понятия не имею. я не совсем уверен, что понимаю, что вы имеете в виду под выходными параметрами - person DForck42; 13.05.2009
comment
Если я что-то не упустил, значение не установлено для параметра номер 0., скорее всего, относится к входному параметру, который не был установлен? - person John Sansom; 13.05.2009
comment
@Jonn Sansom - сообщение об ошибке сбивает с толку, и мое первоначальное предположение заключалось в том, что оно относится к входным параметрам. Однако номер строки кода приложения, из которого возникает исключение (не показан в трассировке стека выше), является вызовом доступа к выходному параметру getInt (). - person Matthew Murdoch; 13.05.2009
comment
@ Thirster42 - в этом случае выходные параметры устанавливаются хранимой процедурой, а не кодом Java (т.е. зарегистрированы с помощью registerOutParameter () в коде Java и определены как OUTPUT в объявлении хранимой процедуры). - person Matthew Murdoch; 13.05.2009
comment
хм ... я не знаю о java или jdbc, возвращающих более одного набора результатов (т.е. возвращающих 2 переменные) в SSRS (или, скорее, он просто выбирает первое значение). Может, происходит что-то подобное? - person DForck42; 13.05.2009
comment
@ Thirser42 - пробовал установить параметры вывода на значение по умолчанию. Это разрешено при определении хранимой процедуры, но значение по умолчанию игнорируется при выполнении. - person Matthew Murdoch; 13.05.2009

arrow_upward
0
arrow_downward

Вы регистрируете выходные параметры? Согласно документам «Все параметры OUT должны быть зарегистрированы перед выполнением хранимой процедуры».

person Vincent Ramdhanie    schedule 13.05.2009

arrow_upward
0
arrow_downward

На ум приходят следующие вещи:

  1. У вас нет RETURN x (где x - это INT, представляющее результат обработки, 0 = успех, все остальное представляет собой предупреждение или ошибку).
  2. Ваш клиентский код не назначает параметр для возвращаемого значения в дополнение к вашему параметру вывода.

Надеюсь это поможет,

Счет

person Community    schedule 23.05.2009

arrow_upward
0
arrow_downward

Декомпиляция класса com.microsoft.sqlserver.jdbc.SQLServerCallableStatement предполагает, что «параметр номер 0» является возвращаемым значением хранимой процедуры.

Это правильно. Если ваше определение хранимой процедуры имеет 11 параметров ввода / вывода, вам действительно нужно определить 12 в вызывающем коде. Параметр 0 - это код возврата.

Например, с SP с одним входным и одним выходным параметром в SSMS вы запускаете это:

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

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

На самом деле у вас есть три параметра, а не два.

person Community    schedule 22.09.2014

arrow_upward
0
arrow_downward

Если у кого-то все еще возникает эта проблема на SQL Server 2008.

У меня была такая же проблема с оператором обновления при попытке установить отметку времени для поля DateTime. Неправильное поле находилось в предложении where с индексом, отличным от указанного.

person Community    schedule 25.04.2016