Parameter Support Objects, Pt II: Support OLAP Parameter Defaults with Datasets

About the Series …

article is a member of the series MSSQL Server Reporting Services. The series is designed to
introduce MSSQL Server Reporting Services (“Reporting Services”),
presenting an overview of its features, with tips and techniques for real-world
use. For more information on the series in general, please see my initial Database Journal article, A New Paradigm for Enterprise Reporting. For the software components, samples and tools
needed to complete the hands-on portion of this article, see BlackBelt Administration: Linked
Reports in Report Manager
, another article within this series.


As we learned in Mastering OLAP Reports: Parameters for Analysis Services
Reporting, Pt. I
and Mastering OLAP Reports: Parameters for Analysis Services
Reporting, Pt. II,
a common enterprise reporting
requirement is the capability to filter reports at run time for specific
information. 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

In the first half of this article,
Automatically Created Parameter Support Objects Pt. I
, we
reviewed type-in and picklist parameters in general, and then
concentrated our focus, once again, upon picklist parameters, which we noted
to be a frequent choice among information consumers for user-friendly operation
within reports. Picklist parameters add value in several ways,
including the inherent elimination of typing errors, as well as the enforcement
of standard selections for report execution. We noted that the design of the picklist
is important in making runtime selections easy, and that picklists that
present long scrolling processes or other cumbersome methods can negatively
affect consumer perceptions, particularly when they are components within
commonly requested reports.

When working with clients to
design and create virtually any enterprise report, I ask questions about the
report’s objectives and intended appearance; moreover, I ask questions about
source data, filtering, and other considerations involved with the information
retrieved by the underlying datasets. When I reach the point at which we
discuss parameterization (the vast majority of reports contain parameters),
I virtually always follow up with questions about desired parameter defaults.

Parameter defaults are important to consider for a couple
of primary reasons. First, and certainly the most basic, is that the absence
of parameter defaults within a report results in one of two things at
runtime: either all sits idle until the information consumer makes parameter
selections and executes the reports, or a blank report is generated (assuming
the Report Parameters dialogs involved allow blank values within
the parameter input / selector boxes). While neither of these
conditions presents an issue to consumers understanding underlying settings,
each can still mean inconvenience in general and perhaps confusion to less
experienced users.

The second design consideration of
importance that surrounds Parameter defaults goes beyond their simple
absence or presence, and focuses more upon their intuitiveness. By
“intuitive,” I mean “dynamically intelligent.” While it is quite desirable to
select among numerous criteria at runtime, we can add finesse to the selections
we offer by having the more likely desired selections, considering the nature
of the report and its typical usage by information consumers, appear as defaults
at runtime. The obvious objective is to make the steps involved in report
execution more efficient, for most of the consumers, most of the time.

In this article, we will continue working with the basic OLAP
report we created in the first half of this article, Customize
Automatically Created Parameter Support Objects Pt. 1
. We will establish a scenario within which we expose the steps
involved in meeting a basic need of a hypothetical client in adding runtime default
that will appear within the parameter picklists of the
report. In examining
the requested addition of parameter defaults within an OLAP report
containing a Matrix data region, we will:

  • Reopen the
    sample Report Server project, AdventureWorks Sample Reports, and
    access the existing sample report we prepared in Pt. I.
  • Discuss
    options for supporting intelligent parameter picklist defaults among the
    three primary layers of the integrated Microsoft business intelligence
  • Discuss an
    approach to meeting the need of our hypothetical client to present parameter
    picklist defaults
    that represent the last period of data entry in
    our cube.
  • Create a dataset
    to provide parameter default support in the Reporting Services
    layer of the client’s BI solution.
  • Overview how
    the various components of the default support solution we propose are
    tied together, as a part of a hands-on practice session where we create and
    align the necessary components to support our parameter defaults.
  • Preview the
    report to observe the effectiveness of our solution in runtime action.
William Pearson
William Pearson
Bill has been working with computers since before becoming a "big eight" CPA, after which he carried his growing information systems knowledge into management accounting, internal auditing, and various capacities of controllership. Bill entered the world of databases and financial systems when he became a consultant for CODA-Financials, a U.K. - based software company that hired only CPA's as application consultants to implement and maintain its integrated financial database - one of the most conceptually powerful, even in his current assessment, to have emerged. At CODA Bill deployed financial databases and business intelligence systems for many global clients. Working with SQL Server, Oracle, Sybase and Informix, and focusing on MSSQL Server, Bill created Island Technologies Inc. in 1997, and has developed a large and diverse customer base over the years since. Bill's background as a CPA, Internal Auditor and Management Accountant enable him to provide value to clients as a liaison between Accounting / Finance and Information Services. Moreover, as a Certified Information Technology Professional (CITP) - a Certified Public Accountant recognized for his or her unique ability to provide business insight by leveraging knowledge of information relationships and supporting technologies - Bill offers his clients the CPA's perspective and ability to understand the complicated business implications and risks associated with technology. From this perspective, he helps them to effectively manage information while ensuring the data's reliability, security, accessibility and relevance. Bill has implemented enterprise business intelligence systems over the years for many Fortune 500 companies, focusing his practice (since the advent of MSSQL Server 2000) upon the integrated Microsoft business intelligence solution. He leverages his years of experience with other enterprise OLAP and reporting applications (Cognos, Business Objects, Crystal, and others) in regular conversions of these once-dominant applications to the Microsoft BI stack. Bill believes it is easier to teach technical skills to people with non-technical training than vice-versa, and he constantly seeks ways to graft new technology into the Accounting and Finance arenas. Bill was awarded Microsoft SQL Server MVP in 2009. Hobbies include advanced literature studies and occasional lectures, with recent concentration upon the works of William Faulkner, Henry James, Marcel Proust, James Joyce, Honoré de Balzac, and Charles Dickens. Other long-time interests have included the exploration of generative music sourced from database architecture.

Get the Free Newsletter!

Subscribe to Cloud Insider for top news, trends & analysis

Latest Articles