MSSQL Server Reporting Services: Managing Reporting Services: Data Connections and Uploads - Page 2

Introduction to the Managing Phase

We learned in the previous two-part article, The Authoring Phase: Overview, that a report definition is created by a developer via the Report Designer (or, optionally, another authoring tool that leverages the Reporting Services API). We overviewed connection, query, layout and other aspects of the design process, within the creation of a tabular report as a practice exercise. After Authoring, the next phase in the report development life cycle, at least for reports that are managed in the first place, is Managing, where the report is processed and rendered.

As we might imagine, there are many variations and options in the steps involved, but, in general, publication of the new report definition to a Report Server designates it as a managed report. In addition to being saved on a Report Server, managed reports are associated with meta data, and have properties, that allow actions to be taken with them, including:

• scheduling
• linking to other reports
• application of security
• movement to various locations
• renaming, deletion and other file maintenance

We can think of processing as taking place in the following general sequence:

• Extraction of the data as specified in the definition (rdl)
• The marriage of the data to the report layout we have defined
• The rendering of the output, as an information product in a desired presentation format.

Once the report is generated (and this can be arranged to happen on a schedule we establish, or upon demand by an information consumer, or even both), the report can be delivered to, or accessed by, consumers in a number of ways. We will discuss these options, and some of the processes involved in their operation, in a subsequent article that focuses on report access and delivery.

In this article, we are going to get a good look at the centralized management of reporting that becomes a reality with Reporting Services. In the middle of it all is the Report Manager, with which we will become familiar over this and subsequent articles. We already mentioned, in the introductory article to this series, that reports can be uploaded to the report server easily from either the Report Designer or the Report Manager; we also noted that the reports can be viewed thereafter via a web browser. Multiple types of security can be assigned during the upload process, as well as elsewhere, for welcome (and rare) flexibility. We will explore these and other features, as well as the degrees of management and administration considerations that make the overhead involved with Reporting Services widely customizable to an organization's needs. We will even examine some aspects of report server administration within the context of management, providing a preview of more detailed examinations that we will undertake with this component in subsequent articles.

Let's get started with our examination of the Managing phase and get a taste of the future that is today with Reporting Services. Because this article focuses on management of reports that are already designed (and in keeping with our objective to make articles "free-standing" with regard to readers being able to participate in each without having joined us in previous articles), we will work with the set of report samples that accompany Reporting Services.

Accessing the Sample Reports

To use the sample reports, we must first install them as a part of Reporting Services Setup. When we installed Reporting Services, we were given this opportunity, with the default installation point for the files being the Samples folder within the Reporting Services program folder. A common example of this default path is as follows:

 C:\Microsoft SQL Server\MSSQL\Reporting Services\Samples\Reports

The documentation for the sample reports (search on "Samples" in the Reporting Services Books Online) informs us that, although the reports are installed, they are not deployed automatically to the Report Server. Since our Managing phase articles concern themselves with this process, in part, and with managing reports that are already created in general, the sample reports present an excellent vehicle by which we can focus on managing, and avoid the diversion of designing considerations. The MSSQL Server 2000 Reporting Services series will afford us, as it progresses, many opportunities to design and write reports that are targeted to specific business needs. Check back frequently to see how I meet real world requirements, within illustrative contexts that have a particularly practical flavor.

If you have already begun to explore managing reports, and have deployed some or all of the samples by manually uploading, using scripts, or publishing via Report Designer, we can still use the sample files in our practice exercises. Simply rename copies, locate them differently, or whatever other action fits your local constraints, and perform the steps along with the rest of us, with your variations in mind as you publish, save, and so forth.

Let's upload the samples as a part of achieving the objectives of the practice exercises in this lesson, as well as in preparation for exercises we will share in future Managing articles. We will use Report Manager versus the Report Designer interface, but rest assured we will get experience from loading with the latter of the two options many times, as the series evolves.