Verification:
Preview the Report and Inspect Effectiveness of Cascading Parameters
Let’s
preview the report to inspect the results of our handiwork. (As is probably
obvious, one of the reasons that I chose hierarchical time for an
example in cascading parameters is the unambiguous relationship between
parent and child level members. We should be able to verify correct operation
simply by knowing, for example, which Months are the children of a given
Calendar Quarter, etc.)
1.
Click the Preview
tab.
DBJ_OLAP_Report.rdl initializes, and the Calendar
Year prompt becomes enabled.
2.
Click the
downward pointing arrow on the right side of the Calendar Year selector.
3.
Select CY
2002 within the Calendar Year parameter picklist.
Once
we make a selection within the Calendar Year dropdown selector, the next
parameter within the cascading chain, Calendar Quarter, becomes
enabled.
4.
Select CY
Q3 from the Calendar Quarter picklist.
We
note that Calendar Quarters 1, 2, 3, and 4 appear,
indicating that what we're seeing is likely to be correct.
5.
Select the
month of August in the Calendar Month parameter picklist.
Again,
we can see that our selections consist of months that belong to parent CY Q3.
6.
Click the View
Report button.
The
report executes quickly and returns the data for the selections we have made
within our parameter picklists. We will “drill down” the August 2002
group that appears upon the face the report, to verify that the dates therein
indeed belong to the month of August, 2002.
7.
Expand the August
2002 group by clicking the “+” sign to its immediate left.
The
underlying dates appear, all of which are appropriately classified children
(specific Dates) of the Month of August, 2002, as
partially shown in Illustration 46.
Illustration 46: Our
Cascading Parameters Deliver as Expected ...
We thus
see that the cascading parameters we have put into place accomplish the
intended ends, and allow us to meet the need as expressed by the information
consumers. We can easily see that the Reporting Services 2005
environment, with its graphical design environment, supports easy and flexible design
of cascading parameters. As we have noted throughout the steps of our
practice procedures, however, potential obstacles exist when we rely upon the
automatic generation of the objects supporting cascading parameters,
particularly in scenarios where we need to modify one or more objects after
their initial creation and alignment. We have examined some of these
considerations, and, if we keep them in mind during design of cascading
parameters, we should be able to enjoy the benefits of the capabilities
they provide in the current version of Reporting Services.
8.
Experiment
further with the report, if desired.
9.
Select File
-> Save All to save our work to this point.
10.
Select File
-> Exit to leave the design environment,
when ready.
Conclusion ...
In
this article, we continued the extended examination of Parameters in Reporting
Services 2005 that we began in Mastering
OLAP Reports: Parameters for Analysis Services Reporting, Pt. I. After
discussing some of the improvements that have come along since Reporting Services 2000, and
specifically focusing upon how the new Query
Builder makes the assembly of the
various objects involved in the construction of cascading parameters
much more straightforward than the steps we had to take in Reporting
Services 2000, we briefly touched upon some of the shortcomings that
accompany automatic generation of those objects, and then moved into our
hands-on practice session.
After
creating a clone of a sample OLAP report, containing a Matrix data
region, we ascertained
connectivity of its shared Analysis Services data source. We then made
structural
modifications to the report, to prepare for our practice exercise session with cascading
parameters. We then
created, within the
graphical Design Mode of the MDX Query Builder, multiple filters
for which parameterization was enabled via the Filter pane
setting. In conjunction with the creation of the parameterized filters,
we inspected the
automatically created Report Parameters and their settings, as well as
the subsequently created datasets underlying the new Report
Parameters. Throughout the steps we undertook, we discussed how the various
components were tied together, and the potential challenges we face in
modifying these objects without consideration of the resulting dependencies.
Finally, we previewed
the report to observe the cascading Parameters in runtime action.
»
See All Articles by Columnist William E. Pearson, III
Discuss this article in the MSSQL Server 2000 Reporting Services Forum.
» 
Comment and Contribute
