Database Journal
MS SQL Oracle DB2 Access MySQL PostgreSQL Sybase PHP SQL Etc SQL Scripts & Samples Links Database Forum

» Database Journal Home
» Database Articles
» Database Tutorials
MS SQL
Oracle
DB2
MS Access
MySQL
» RESOURCES
Database Tools
SQL Scripts & Samples
Links
» Database Forum
» Sitemap
Free Newsletters:
DatabaseDaily  
News Via RSS Feed


follow us on Twitter
Database Journal |DBA Support |SQLCourse |SQLCourse2
 

Featured Database Articles

MS SQL

Posted Jun 19, 2006

BlackBelt Administration: Linked Reports in Report Manager

By William Pearson

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 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:

Server Requirements

  • 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

Client Requirements

  • Microsoft Internet Explorer 6.0 with scripting enabled

  • Business Intelligence Development Studio (optional)

Sample Files

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 component 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 virtually 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.

Overview

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. 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. Even in the simplest implementations, there is typically at least some need to exercise control over what information consumers can access. 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 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." Progress can thus 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). 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.

A common scenario I come across in implementing Reporting Services lies in using folder security to control report access, at least within the development cycles, and sometimes beyond. In many cases, the reports that reside in a given folder, say for the corporate finance department, are totally different from reports that are deployed within, for instance, the folder designated to inventory management. However, 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 events, such as report modifications, occur.

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. The concept of Linked Reports becomes quite attractive when we come across needs to make either identical or multiple versions of the same report available in various folders – a capability that has proven itself 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 this article, we will get some hands-on exposure to Linked Reports. We will discuss the general concepts, and then set up a scenario within which we deploy a sample report, and then perform the steps of setting up Linked Reports in multiple folders. 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 in Report Manager, to house Linked Reports for different consumer groups;

  • Create Linked Reports 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 to ascertain the effectiveness of our solution.



MS SQL Archives

Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 




Latest Forum Threads
MS SQL Forum
Topic By Replies Updated
SQL 2005: SSIS: Error using SQL Server credentials poverty 3 August 17th, 07:43 AM
Need help changing table contents nkawtg 1 August 17th, 03:02 AM
SQL Server Memory confifuration bhosalenarayan 2 August 14th, 05:33 AM
SQL Server Primary Key and a Unique Key katty.jonh 2 July 25th, 10:36 AM