About the Series ...
This article is a member of the series MSSQL Server Reporting Services. The series is designed to introduce MSSQL Server Reporting Services ("Reporting Services"), with the objective of presenting an overview of its features, together with tips and techniques for its real-world use. For more information on the series, please see my initial Database Journal article, A New Paradigm for Enterprise Reporting.
As I have stated since the charter article of the series, published about the time Reporting Services was first publicly released, my conviction is that Reporting Services will commoditize business intelligence, particularly in its role as a presentation component within an integrated Microsoft BI solution. Having been impressed from my first exposure to this exciting application, when it was in early beta, my certainty in its destiny grows stronger by the day, as I convert formerly dominant enterprise business intelligence systems, such as Cognos, Business Objects / Crystal, MicroStrategy, and others, to the Reporting Services architecture. I receive constant requests to conduct strategy sessions about these conversions with large organizations in a diverse range of industries the interest grows daily as awareness of the solution becomes pervasive. Indeed, the five- to six-plus figures that many can shave from their annual IT budgets represent a compelling sweetener to examining this incredible toolset.
Note: To follow along with the steps we undertake within the articles of this series, the following components, samples and tools are recommended, and should be installed / accessible, according to the respective documentation that accompanies MSSQL Server 2005:
Microsoft SQL Server 2005 Reporting Services
Microsoft SQL Server 2005 Database Services
The AdventureWorks sample databases (relational and Analysis Services)
Microsoft SQL Server 2005 Analysis Services
For purposes of the practice exercises within this series, we will be working with samples that are provided with MSSQL Server 2005. The samples with which we are concerned include, predominantly, the Adventure Works DW sample databases and other samples. This database and companion samples are not installed by default in MSSQL Server 2005. The samples can be installed during Setup, or at any time after MSSQL Server has been installed.
The topics "Running Setup to Install AdventureWorks Sample Databases and Samples" in SQL Server Setup Help or "Installing AdventureWorks Sample Databases and Samples" in the Books Online (both of which are included on the installation CD(s), and are available from www.Microsoft.com and other sources, as well), provide guidance on samples installation. Important information regarding the rights / privileges required to accomplish samples installation, as well as to access the samples once installed, is included in these references.
Note: Current Service Pack updates are assumed for the operating system, along with the applications and components listed above and the related Books Online and Samples. Images are from a Windows 2003 Server environment, but the steps performed in the articles, together with the views that result, will be quite similar within any environment that supports MSSQL Server 2005 and its constituent applications.
About the BlackBelt Articles ...
As I have stated in earlier BlackBelt articles, one of the greatest challenges in writing tutorial / procedural articles is creating each article to be a freestanding document that is complete unto itself. This is important, because it means that readers can complete the lesson without reference to previous articles or access to objects created elsewhere. When our objective is the coverage of a specific technique surrounding one or more components of a report, a given administrative function surrounding reports in general, and other scenarios where the focus of the session is not the creation of reports, per se, challenges can arise because a report or reports often has to be in place before we can begin to cover the material with which the article concerns itself.
The BlackBelt articles represent an attempt to minimize the setup required in simply getting to a point within an article where we can actually perform hands-on practice with the component(s) or method(s) under consideration. We will attempt to use existing report samples or other "prefabricated" objects that either come along as part of the installation of the applications involved, or that are readily accessible to any organization that has installed the application. While we will often have to make modifications to the sample involved (we will actually create a copy, to allow the original sample to remain intact), to refine it to provide the specific backdrop we need to proceed with the object or procedure upon which we wish to concentrate, we will still save a great deal of time and distraction in getting to our objective. In some cases, we will have to start from scratch with preparation, but my intention with the BlackBelt articles will be to avoid this, if at all possible.
For more information about the BlackBelt articles, see the section entitled "About the BlackBelt Articles" in BlackBelt Components: Manage Nulls in OLAP Reports.
In BlackBelt Administration: Linked Reports in Report Manager, we introduced Linked Reports. We noted that, as administrators of enterprise reporting systems can attest, management of the business intelligence solution does not end when we deploy / publish the reports to the Report Server. We discussed the fact that, within Reporting Services, many properties and options can be set and maintained at the Report Server level, through the Report Manager, or an alternative interface. We also noted that, even in the simplest implementations, there is usually at least some need to exercise control over what information consumers can access. We then mentioned that this is often initially handled through the management of folder security, which comes "out of the box" with Reporting Services, and often provides a great starting point for new implementations. We related a reason that this is so: we can thus get started with the presentation layer of a business intelligence system, affording the organization the capability to gather business requirements and develop reports that consumers can "road test." In this manner, we reasoned, progress can be taking place toward the crafting of a report library, in the developmental meantime, regardless of the ultimate report delivery mechanism (dashboards, scorecards, portals, other customized interfaces, or combinations of these things). The idea, we stated, was that it is often to our advantage to begin development quickly, and to deliver reports that can be executed by users, who can be feeding them back with their input, as we continue to rapidly turn out the new report library.
As I stated in BlackBelt Administration: Linked Reports in Report Manager, a common scenario I come across in implementing Reporting Services lies in using folder security to control report access, within the development cycles and often beyond. In many cases, reports that reside in a given folder (say, a set of reports for the corporate finance department), are totally different from reports that are deployed within other folders (an example of which might be a folder dedicated to housing inventory management reports). Nevertheless, we often encounter situations where the same report may need to be placed within multiple folders. Placing duplicates of the same report in the folders involved might seem like a simple solution, but can lead to added overhead from an administration perspective when maintenance events, such as report modifications, occur.
As we learned in BlackBelt Administration: Linked Reports in Report Manager, Reporting Services offers a way to handle this without the overhead: Linked Reports. When we use Linked Reports, we create a single "master" report, and then deploy the .rdl file to a single folder. We then create Linked Reports within the other folders from which access to the report is required. We noted that the concept of Linked Reports becomes quite attractive when we come across needs to make either identical reports, or multiple similar versions of the same report, available in various folders. These capabilities have proven themselves quite popular with many of my clients who faced scenarios such as the need to provide an identical (in layout / format) sales report to numerous departments, regions or even individual salespersons, but with each report's contents specific to the department, region or salesperson accessing or receiving it. Linked Reports allow us to provide this capability to our clients and / or the consumers within our organizations with ease, while affording a single point of actual deployment and centralized administration.
In BlackBelt Administration: Linked Reports in Report Manager, we got some hands-on exposure to Linked Reports, performing most of the post-deployment setup at the Report Manager level. In this article, we will again discuss general concepts, to make it a "standalone procedure" for those who wish to perform many of the setup steps for Linked Reports from within SQL Server Management Studio, where many organizations choose to centralize BI maintenance and management functions, once they are deployed. We will set up a scenario, as we did in the previous article, within which we deploy a sample report, and then will perform the steps of setting up Linked Reports in multiple folders. Our intended results will be identical to those of the last article; we will simply accomplish much of the setup from SQL Server Management Studio instead of from the Business Intelligence Development Studio. As a part of our examination of the steps involved in establishing Linked Reports within Reporting Services, we will:
- Open the sample Report Server project, AdventureWorks Sample Reports, and ascertain connectivity of its shared data source;
- Create a clone of an existing sample OLAP report, with which to perform our practice exercise;
- Make limited structural changes to the clone report, based upon a sample SQL Server Analysis Services cube, to meet the business requirement of a hypothetical group of information consumers to use it as a basis for Linked Reports;
- Preview the clone report to ascertain its readiness for deployment;
- Deploy the report to a common folder within Report Manager;
- Create folders within SQL Server Management Studio, to house Linked Reports for different consumer groups;
- Create Linked Reports (again from within SQL Server Management Studio), within the new consumer group folders, based upon the common source .rdl file;
- "Hard code" a default, hidden parameter within each Linked Report to restrict the data to the intended consumer group audiences;
- Preview a Linked Report from the presentation layer, to ascertain the effectiveness of our solution.