Using Parameters in MS Reporting Services (SQL Server 2008) against an ODBC data source

Question

I writing a report in Visual Studio that takes a user input parameter and runs against an ODBC datasource. I would like to write the query manually and have reporting services replace part of the where clause with the parameter value before sending it to the database. What seems to be happening is that the @parmName I am assuming will be replaced is actually being sent as part of the SQL statement. Am I missing a configuration setting somewhere or is this simply not possible?

I am not using the filter option in the tool because this appears to bring back the full dataset from the database and do the filtering on the SQL Server.

Answer 1

It sounds like you'll need to treat the SQL Statement as an expression. For example:

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

If the where clause is a string you would need to do the following:

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

Important: Do not use line breaks in your SQL expression. If you do you will get an error.

Holla back if you need any more assistance.

Answer 2

Doesn't ODBC use the old "?" syntax for parameters? Try this:

select col1, col2 from table1 where col3 = ?

The order of your parameters becomes important then, but it's less vulnerable to SQL injection than simply appending the parameter value.

Answer 3

Encountered same problem trying to query an access database via ODBC.

My original query: SELECT A.1 FROM A WHERE A.1 = @parameter resulted in error. Altered to: SELECT A.1 FROM A WHERE A.1 = ?.

You then have to map the query parameter with your report parameter.

Answer 4

I am a bit confused about this question, if you are looking for simple parameter usage then the notation is :*paramName* , however if you want to structurally change the WHERE clause (as you might in sql+ using ?) then you should really be using custom code within the report to define a function that returns the required sql for the query.

Unfortunately, when using custom code, parameters cannot be referenced directly in the generated query but have to have there values concatenated into the resultant String, thus introducing the potential for SQL injection.