February 23, 2007 01:23 PM

Following the Rules with Reporting Services

A 3-part workaround solves a sticky business-rule problem for queries against Analysis Services
Rating: (0)
SQL Server Magazine
InstantDoc ID #94827
SQL Server 2005 Reporting Services does the yeoman's work for reports that extract data from SQL Server 2005 Analysis Services. Reporting Services is good at providing the framework for report development, parameter selection, report deployment, and controlling report access. However, sometimes Reporting Services behaves differently than expected or desired when dealing with Analysis Services data and you need to find imaginative solutions to work around Reporting Services' limitations. Unfortun...

...This article is for paid Professional Members only.

Already a Professional Member? Please log in now:

NOT A PROFESSIONAL MEMBER? YOU CHOOSE:

Professional Membership

Monthly

Annual

VIP Membership

Monthly

Annual

Add a Comment

Seems like there would be an easier way to do this. Why not just put an expression in the Visibility property and skip the extra code block altogether. For the parameter, use the level.ordinal field in the dataset as the value of the parameter, and then use something like this in the Visibility property...
IIF(Parameters!Geography.Value <= Fields!RowLevel.Value, False, True)
where Fields!RowLevel.Value would be the rowlevel of that row in the report. The only reason I can see for the extra work in this articles solution would be to try to isolate the code used in the visibility property so it can be used in other places and if modification needs to be done it can be done in one place. Still, in a report this is not really needed. Reports tend to be simple enough (even the complex ones) that it is not necessary.

Richard3/22/2007 1:52:22 AM


Seems like there would be an easier way to do this. Why not just put an expression in the Visibility property and skip the extra code block altogether. For the parameter, use the level.ordinal field in the dataset as the value of the parameter, and then use something like this in the Visibility property...
IIF(Parameters!Geography.Value <= Fields!RowLevel.Value, False, True)
where Fields!RowLevel.Value would be the rowlevel of that row in the report. The only reason I can see for the extra work in this articles solution would be to try to isolate the code used in the visibility property so it can be used in other places and if modification needs to be done it can be done in one place. Still, in a report this is not really needed. Reports tend to be simple enough (even the complex ones) that it is not necessary.

Richard3/22/2007 1:52:22 AM


You must log on before posting a comment.

Are you a new visitor? Register Here
GOOGLE LINKS
SPONSORED LINKS
FEATURED LINKS