2013-12-06 5 views
0

У меня есть хранимая процедура, вызываемая из отчета SSRS. Хранимая процедура сама по себе работает нормально (например, код ниже возвращает ожидаемые результаты). Отчет проходит в двух параметрах: DateTime, но они, по-видимому, полностью игнорируются. Как я могу проверить значения, переданные в хранимую процедуру из хранимой процедуры?Показать параметры от SSRS до хранимой процедуры

USE [MyDatabase] 
GO 
DECLARE @return_value int 
EXEC @return_value = [reports].[uspMyReport] 
     @StartDate = N'3/15/2013', 
     @EndDate = N'3/16/2013' 

SELECT 'Return Value' = @return_value 
GO 

С с ЗАЯВОК, в общем наборе данных sproc называется так:

EXEC reports.[uspMyReport] @StartDate, @EndDate 

Ответ: Я могу видеть значение, которое было передано в хранимой процедуре, как так:

DECLARE @StartDateString VARCHAR(50) 
SELECT @StartDateString = CAST(@StartDate AS VARCHAR) 
RAISERROR(N'StartDate: %s', 18, 0, @StartDateString) 
RETURN 
+0

Проводка кода sproc на самом деле невозможна, и это не поможет. Вышеупомянутый код вызывает sproc с действительными параметрами, и sproc работает правильно. Таким образом, я думаю, что в отчете передаются недопустимые параметры (хотя они хорошо смотрятся на стороне SSRS), и я хотел бы видеть, что они находятся внутри sproc. –

+1

Пожалуйста, добавьте команду SQL из отчета SSRS, чтобы было ясно, как вы вызываете эту процедуру. –

ответ

1

Есть несколько способов, чтобы проверить, как далеко значение параметров получит:

Вы могли бы вызвать ошибку как описано здесь: The "right" way to do stored procedure parameter validation Это проверяет, достигли ли значения хранимой процедуры: Если они этого не делают, параметры хранимогопроцедуры, вероятно, не связаны с параметрами отчета, и вам необходимо настроить отчет. Если они это сделают, окончательный запрос выбора каким-то образом их не использует, и вам нужно исправить сохраненныйпродукт.

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

И, наконец, вы можете запустить профилировщик SQL Server непосредственно перед запуском отчета и посмотреть, как именно ваша процедура вызывается из SSRS. Таким образом, вам не нужно изменять процедуру для отладки самого вызова.

+0

Ваше первое предложение - это то, что я ищу, в основном. Теперь я использую RAISEERROR для возврата значения входного параметра. (Показано выше) –

Смежные вопросы