MSSQL Server Reporting Services: Mastering OLAP Reporting: Cascading Prompts

About the Series …

This is the sixth article of the series MSSQL
Server 2000 Reporting Services. The series is designed to introduce
MSSQL Server 2000 Reporting Services ("Reporting Services"), with the
objective of presenting an overview of its features, together with many tips
and techniques for real-world use. I will also use the column as a vehicle for
sharing my conviction in Reporting Services’ role as a new paradigm in
enterprise reporting. As I advise clients on a more and more frequent basis
these days, this is the future in a big way. I hope you will consider my input
valuable, and that you will investigate closely the savings and advanced functionality
that will soon be available to anyone with an MSSQL Server 2000 (and beyond)
license.

For
many of the articles in this series, it is assumed that you have prepared
security to allow "power user" status in virtually every regard. For
details on the specifics of the adjustments necessary to quickly allow full
freedom to complete the exercises in this and subsequent articles, as well as
important assumptions regarding rights and privileges in general, please see earlier
articles in our series, as well as the Reporting Services Books Online.

Overview

A common requirement of enterprise
reporting is the capability for information consumers to filter reports at run
time for specific information they need. This is typically managed via parameterization,
also known as "prompting," where the filter criteria is
requested (and hence the consumer is "prompted") when the report is
run. Depending upon the parameter type (the most common are type-in
and picklist), the filters are typically enacted when the consumer types
or selects a value, or a series of values.

Type-in parameters accept directly typed user input for the value
upon which the report is based. Alternatively, the picklist presents a
selection of choices to a consumer based upon a static file, a dataset from a
larger data source, or through other means. The picklist is often the tool of
choice, because of its inherent elimination of typing errors. A
well-constructed picklist makes selection easy for the consumer, who is not
often pleased with a long scrolling process, or other cumbersome method, as the
initial step in generating a commonly requested report.

A further
refinement of the picklist parameter type is the cascading picklist. In
a cascading picklist scenario, the set of values of one parameter depends upon
the value chosen in another, typically previous parameter. For example, the
first parameter could present a list of states within which the organization’s
customers reside. When the consumer selects a state, the set of possible values
presented from which to select the second parameter is updated with a list of
cities within the chosen state. A third parameter could then display a list of
customers within the selected city. The customer name or other ID number could
then be used to filter the report to a particular customer. The process of
filtering a list of parameter values, based upon a value from a previous
parameter, is described as "cascading" (and is also known as "hierarchical"
or "dependent").

I have
implemented cascading parameters in numerous ways. One of my favorite ways to
accomplish any sort of picklist parameterization, and especially applicable
here, is to create support objects within the MSAS cube that is used as a data
source for the reports under consideration. For an example of implementing
support for a hierarchical picklist in this manner, see my Database
Journal article Create
a Cube-Based Hierarchical Picklist.

In this
article, we will provide a basic approach to creating cascading picklists
completely within Reporting Services. Subsequent articles will introduce
additional approaches and nuances, but our objective here is to isolate and expose
the rudimentary concepts. In this session, we will:

• Discuss parameterization
  in general, and cascading picklists specifically;

• Create a clone
  of an existing sample report to modify for a hypothetical business need;

• Add several components
  to the report to support cascading parameters;

• Discuss the MDX
  queries that underlay the various datasets;

• Emphasize the
  importance of physical arrangement when parameterizing an MDX query;

• Verify parameterization
  within the overall operation in the report.