in

jetlounge

the minty fresh blog that whitens your teeth!


Syndication


Strange Refresh of Parameters in SQL Reporting Services

by David Leibowitz | December 13, 2007 | Comments: 7

Input Parameters should refresh on your SSRS report if there are dependencies, for instance a list of valid Sales Reps might be dependent upon a selection of Sales Territory first.
It makes sense that a change in Territory would trigger a refresh or postback in order to regenerate a list of valid values.

However, you may notice some strange behavior that causes a postback of parameters even when no dependency exists.

According to Microsoft, if a default value or valid values list is "too complex" for the RS engine to comprehend at runtime it will determine that it is dependent and therefore a candidate for refreshing.

What this really boils down to is default expressions. Your expression could be as simple as =Year() to default to the current year on a list, or even =2006. Seems simple enough, but once you throw that equals sign in there, RS crosses its' arms and says "looks like VB to me, so I'm going to reevaluate it." ...EVERY time ANY other parameter changes. And that means a nasty post back, and time wasted in front on the screen to a user.

There is a workaround, as a dataset doesn't send persnickity RS into such a tizzy. If you can, take those VB expressions and turn them into datasets that return values based on an SQL statement.

So =Year()  in the expression would become something like

Select Year(getdate()) as CurYear

Then set the default to use that new dataset and the CurYear value.

For simple fixed values, you can do this as:

Select 2006 as CurYear

More complex statements may take a bit of code, but the rewards will be a friendlier user interface that doesn't need to refresh every single parameter on screen when you make one little change to a filter.

 

del.ico.us digg this technorati BlinkList Furl reddit DotNetKicks google! live Facebook Stumble Upon Yahoo!



Comments

 

Ivo said:

We have a collection of reports where parameter drop downs are based on the return values of stored procedures.  These, however, STILL result in nasty postbacks upon value change.

January 9, 2008 2:45 PM
 

david said:

If those stored procedures have input parameters (ie. dependencies)..then yes you will have that round trip.

January 14, 2008 8:55 AM
 

MiB said:

One of my datasets look like this:

select '' Name, 0 DisplayOrder

union

SELECT Name, DisplayOrder FROM [CategoryList]

What should I have change to prevent the post back on report?

Cheers,

June 27, 2008 4:00 AM
 

BusOwner said:

1) Can you tell me if this will work for Multivalue items?  

2) I have a Start Date and End Date parameters for which I the default date is today's date. I used the following query in a DataSet :

SELECT DATEADD(dd, 0, DATEDIFF(dd, 0, GETDATE())) AS TodaysDate

and set TodaysDate as the default value for both of those items. It still does a postback.

May be this technique will work only for non-Multivalue list only? I'd be grateful to know what has been your experience in this?

September 19, 2008 11:19 AM
 

Sander van Haaff said:

Great tip. Works for me!

September 15, 2009 7:34 AM
 

Andrew Chen said:

the valid values list of 2nd parameter is populated by a mdx query,and it always refreshes whenever the first parameter is changed,although they are independent.

is there a work-around?thanks.

chenshx#live.cn(replace # with @)

October 8, 2009 11:26 PM
 

Imre said:

Thank you very much, for sharing this workaround! It's strange that no one knows about it. :) Thanks again.

July 13, 2011 6:19 PM

Leave a Comment

(required)  
(optional)
(required)  
Add
Powered by Community Server (Non-Commercial Edition), by Telligent Systems