Uso de parámetros en MS Reporting Services (SQL Server 2008) contra una fuente de datos ODBC

Question

Estoy escribiendo un informe en Visual Studio que toma un parámetro de entrada del usuario y lo ejecuta en una fuente de datos ODBC.Me gustaría escribir la consulta manualmente y que los servicios de informes reemplacen parte de la cláusula donde con el valor del parámetro antes de enviarla a la base de datos.Lo que parece estar sucediendo es que el @parmName Supongo que se reemplazará y en realidad se enviará como parte de la declaración SQL.¿Me falta algún ajuste de configuración en alguna parte o simplemente no es posible?

No estoy usando la opción de filtro en la herramienta porque parece recuperar el conjunto de datos completo de la base de datos y realizar el filtrado en SQL Server.

Answer 1

Parece que necesitarás tratar la declaración SQL como una expresión.Por ejemplo:

="Select col1, col2 from table 1 Where col3 = " & Parameters!Param1.Value 

Si la cláusula donde es una cadena, deberá hacer lo siguiente:

="Select col1, col2 from table 1 Where col3 = '" & Parameters!Param1.Value & "'"

Importante:No utilice saltos de línea en su expresión SQL.Si lo hace, obtendrá un error.

Hola, vuelve si necesitas más ayuda.

Answer 2

¿ODBC no usa el viejo "?" sintaxis para parámetros?Prueba esto:

select col1, col2 from table1 where col3 = ?

El orden de sus parámetros se vuelve importante entonces, pero es menos vulnerable a la inyección SQL que simplemente agregar el valor del parámetro.

Answer 3

Encontré el mismo problema al intentar consultar una base de datos de acceso a través de ODBC.

Mi consulta original: SELECT A.1 FROM A WHERE A.1 = @parameter resultó en un error.Modificado a: SELECT A.1 FROM A WHERE A.1 = ?.

Luego debe asignar el parámetro de consulta con su parámetro de informe.

Answer 4

Estoy un poco confundido acerca de esta pregunta, si busca un uso de parámetros simple, entonces la notación es:*paramName* , sin embargo, si desea cambiar estructuralmente el WHERE cláusula (como podría hacerlo en sql+ usando?), entonces realmente debería usar un código personalizado dentro del informe para definir una función que devuelva el sql requerido para la consulta.

Desafortunadamente, cuando se utiliza código personalizado, no se puede hacer referencia a los parámetros directamente en la consulta generada, sino que deben tener sus valores concatenados en la cadena resultante, lo que introduce la posibilidad de SQL inyección.