Usando parâmetros no MS Reporting Services (SQL Server 2008) em uma fonte de dados ODBC

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.