SQL Reporting Services Parameter Dependency Trick
SQL Server Reporting Services has a bug that annoys me. I have a report with SQL based parameters (a dropdown list), and a date range that I default using a Reporting Service expression.
The bug occurs when users run the report multiple times. Changing the dropdown option reverts the date to the default. Reporting Services assumes that a change in the dropdown should revert all non-sql based parameters to their default values. Very annoying for the users, and there's no way around it in the current version of Reporting Services using parameter dependencies. The workaround I came up with is simply to change the date parameter and make it a SQL query rather than a Reporting Services expression. This prevents or tricks Reporting Services into leaving the parameter alone when users change other SQL-based parameters. I added a DataSet containing a SQL query with my date logic (in this case, the first date of the current month).
//************************************************************
// Default report date to the first day of current month
// -----------------------------------------------------------
// Note: We use a dataset for this instead of an expression
// to avoid parameter dependencies, which cause our dates to
// get reset when the location parameter is changed in the
// Reporting Services report viewer
//************************************************************
SELECT REPORT_DATE = DATEADD(m, -1, DATEADD(m, DATEDIFF(m, 0, GETDATE()), 0))
// Default report date to the first day of current month
// -----------------------------------------------------------
// Note: We use a dataset for this instead of an expression
// to avoid parameter dependencies, which cause our dates to
// get reset when the location parameter is changed in the
// Reporting Services report viewer
//************************************************************
SELECT REPORT_DATE = DATEADD(m, -1, DATEADD(m, DATEDIFF(m, 0, GETDATE()), 0))
No comments:
Post a Comment