Usando parâmetros no MS Reporting Services (SQL Server 2008) em uma fonte de dados ODBC
-
08-06-2019 - |
Pergunta
Estou escrevendo um relatório no Visual Studio que usa um parâmetro de entrada do usuário e é executado em uma fonte de dados ODBC.Gostaria de escrever a consulta manualmente e fazer com que os serviços de relatório substituíssem parte da cláusula where pelo valor do parâmetro antes de enviá-la ao banco de dados.O que parece estar acontecendo é que o @parmName
Presumo que será substituído está sendo enviado como parte da instrução SQL.Estou faltando uma configuração em algum lugar ou isso simplesmente não é possível?
Não estou usando a opção de filtro na ferramenta porque parece trazer de volta o conjunto de dados completo do banco de dados e fazer a filtragem no SQL Server.
Solução
Parece que você precisará tratar a instrução SQL como uma expressão.Por exemplo:
="Select col1, col2 from table 1 Where col3 = " & Parameters!Param1.Value
Se a cláusula where for uma string, você precisará fazer o seguinte:
="Select col1, col2 from table 1 Where col3 = '" & Parameters!Param1.Value & "'"
Importante:Não use quebras de linha na sua expressão SQL.Se você fizer isso, receberá um erro.
Volte se precisar de mais ajuda.
Outras dicas
O ODBC não usa o antigo "?" Sintaxe para parâmetros?Experimente isto:
select col1, col2 from table1 where col3 = ?
A ordem dos seus parâmetros torna-se importante, mas é menos vulnerável à injeção de SQL do que simplesmente anexar o valor do parâmetro.
Encontrei o mesmo problema ao tentar consultar um banco de dados de acesso via ODBC.
Minha consulta original: SELECT A.1 FROM A WHERE A.1 = @parameter
resultou em erro.Alterado para: SELECT A.1 FROM A WHERE A.1 = ?
.
Em seguida, você deve mapear o parâmetro de consulta com o parâmetro do seu relatório.
Estou um pouco confuso sobre esta questão. Se você está procurando um uso simples de parâmetros, a notação é:*paramName*
, no entanto, se você quiser alterar estruturalmente o WHERE
cláusula (como você faria no sql + usando?), então você realmente deveria usar código personalizado no relatório para definir uma função que retorne o sql necessário para a consulta.
Infelizmente, ao usar código personalizado, os parâmetros não podem ser referenciados diretamente na consulta gerada, mas precisam ter seus valores concatenados na String resultante, introduzindo assim o potencial para SQL
injeção.