Передача многозначного параметра в подотчет

У меня возникла проблема при работе с multivalue параметрами между отчетами.

У меня есть основной отчет, в котором я определил многозначный параметр, который я использую для запуска SQL-запроса для заполнения его набора данных. Параметр используется в предложении WHERE следующим образом:

WHERE values IN (@parameter)

Он работает нормально и получает ожидаемые данные.

Затем этот основной отчет передает этот параметр подотчету. Параметр также определяется как многозначный в подотчете, и, насколько я вижу в раскрывающемся списке параметров, он получает значения правильным образом. Что-то вроде этого: А, В, С

Дело в том, что запрос, который заполняет набор данных вложенного отчета, ничего не возвращает. Он также имеет предложение WHERE, определенное как в основном отчете (который уже работает)

WHERE values IN (@parameter)

Если я запускаю запрос вручную, жестко кодируя значения примерно так:

WHERE values IN ('A', 'B', 'C')

он работает, но когда я пытаюсь использовать параметр, это не так. Итак, каким-то образом он теряет формат или значения на пути.

Я попробовал это решение в определении набора данных подотчета, которое было предложено в другом потоке:

 =join(Parameters!<your param name>.Value,",")

Но у меня это не работает, набор данных все еще пуст.

Любые идеи о том, что мне не хватает?

Спасибо! :)


sql parameters reporting-services multivalue subreport
person monican    schedule 05.12.2012    source источник

Ответы (3)


arrow_upward
13
arrow_downward

Это должно «просто работать». Убедитесь, что параметр в подотчете настроен как многозначный, и я обычно использую тот же запрос, что и в родительском отчете, для предоставления «Доступных значений».

Убедитесь, что вы передаете весь параметр во вложенный отчет: в свойствах вложенного отчета в родительском отчете значение параметра должно быть [@MyParamName], а не <<Expr>>. Если он читается как последний, отредактируйте выражение и убедитесь, что оно не имеет (0) в конце. но =Parameters!MyParamName.Value правильно, нет =Parameters!MyParamName.Value(0)

person Jamie F    schedule 05.12.2012
comment
Вы правы, это должно было сработать, но не сработало. Итак, я удалил отчет и снова создал его с нуля, это сработало. Видимо, я что-то забыл в середине. Спасибо в любом случае за ваш ответ - person monican; 06.12.2012
comment
Спасибо, это помогло мне заставить мою работу работать. Важно: Параметр во вложенном отчете настроен как многозначный, и для предоставления доступных значений используйте тот же запрос, что и в родительском отчете.. Важно: В свойствах вложенного отчета в родительском отчете значение параметра должно читаться как [@MyParamName], а не <<Expr>>. Эти советы помогли мне. - person SherlockSpreadsheets; 29.03.2019

arrow_upward
3
arrow_downward

Просто создал отчет с нуля снова, и это сработало. Я, должно быть, забыл что-то в середине.

В любом случае, на всякий случай, если это кому-то нужно, два параметра, один в основном отчете и один в подотчете, должны быть определены как многозначные. Затем в своем запросе вы должны использовать IN в своем WHERE clase, что-то вроде этого:

WHERE field IN (@parameter)

И больше ничего не нужно. Мне не нужно было делать следующее:

=join(Parameters!<your param name>.Value,",")

Это просто сработало для меня

person monican    schedule 05.12.2012

arrow_upward
3
arrow_downward

Думаю, я знаю, что вы сделали, поскольку меня привлекла сюда та же проблема. Подотчеты были настроены нормально, но при вводе привязки параметра в родительском отчете раскрывающийся список Value действительно предлагал мой параметр, поэтому я использовал построитель выражений, чтобы выбрать его. Это оставило серый маркер << Expr >> в значении и работало только тогда, когда у меня было только одно значение, выбранное из списка. Когда я заменил это на [@MyParam], он работал нормально, независимо от количества выбранных значений. Когда я посмотрел на построитель выражения значения, созданный немного ближе, у него было =Parameters!MyParam.Value(0). Удаление (0) также исправляет это.

person Swanny    schedule 24.10.2014