Reporting Services puts parameter selection before the top of the report, with (at most) 2 parameters on a row. If your report has a lot of parameters (my example below has 5), the parameter section can take up a lot of room:
As an aside, having multiple parameters is better than having multiple reports which differ only by a WHERE clause in the database. Parameters are your friend - it's just the parameter display (which is not configurable at all) that I'm trying to look at here.
So taking up a lot of screen real estate with parameters is a bad thing. If the report already has default values set for parameters (a must), I reckon that if a parameter only has a few options, and the default is going to be used 80% of the time, one solution is to mark the parameter as "Hidden" and then provide a link in the report which will toggle it. Here's my example of the same report with only 3 parameters:
In my example with only 3 parameters, more of the space is dedicated to the report and less to the parameters. I've shown what the current current parameters are so when the report is printed or exported, the settings used to run it are visible.
My "click to change" text is just a label that has the "Action" property set to run the same report with the changed parameter (remember, I used parameters that only have two values). An additional task is to set the text from an expression, but I reckon getting the text into this plain english format is worth it.
Side another aside, I thought I'd blog this because I've been listening to Adam Cogan's session from SQL Code Camp NZ and checking out the SSW Rules to Better SQL Reporting Services 2005, both very helpful. Just thought I'd add to the collected wisdom :-)
Tags: reporting services, parameters, design, default