MSSQL Server Reporting Services: Mastering OLAP Reporting: Cascading Prompts

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.