DatabaseIntroducing Microsoft Reporting Services

Introducing Microsoft Reporting Services content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

What You Will Learn:

1.1 What is RS?
1.2 RS at a glance
1.3 RS architecture
1.4 Understanding Report Processing
1.5 Delivering reports
1.6 What is the report lifecycle?
1.7 RS in action

1.8 Evaluating RS

1.9 Summary

1.10 Resources

So much information, so little time … the character “Poison Ivy” would likely say if the Batman saga was taking place in today’s enterprise.

We all know that the boom is history and so are the lavish IT budgets. In the doldrums of the economic recovery, organizations tend to spend their money on streamlining internal processes to gain a competitive advantage. According to Microsoft, today’s information workers spend as much as 80 percent of their time gathering information, with only 20 percent left to analyze it and make a decision. In many organizations, such requests consume significant IT and development resources. Too often, Excel spreadsheets are the prevalent reporting tools today and manual data entry or “pencil-pushing” is among the top reasons for inaccurate data and wrong decisions. Aware of these issues, Microsoft initiated the Microsoft SQL Server 2000 Reporting Services project at the beginning of the new millennium, with a bold vision to “enable employees at all levels of an organization to realize the promise of Business Intelligence to promote better decision making.”

This chapter [From the Manning book Microsoft Reporting Services in Action] provides a panoramic view of Reporting Services (RS). Throughout the rest of this book I will use the terms Reporting Services and RS interchangeably. You will see

  • Why RS is such a compelling choice for enterprise reporting
  • The main parts of the RS architecture
  • The report-generation process and report lifecycle
  • The steps for creating your first RS report


Regardless of the alphabet soup of terms and acronyms that are popping up like daisies almost every day and that have probably become a part of your IT vocabulary—terms such as BI (business intelligence), OLAP (online analytical processing), data mining, DSSs (decision support systems), EISs (executive information systems), digital dashboards, enterprise portals, and enterprise data buses—the purpose of enterprise reporting is to simply “get out” what was “put in.” Therefore, for many applications, reporting represents the last, and often most important, stage of the IT pipeline.

To clarify the last point, let’s consider a typical scenario that RS can address effectively. Let’s say that an organization has built a web portal for submitting orders online. As the business grows, the same organization may need to implement a reporting infrastructure to analyze sales data and understand its business, for example, to find out the top-selling products, customer demographics, and so forth. To accomplish this goal, the organization could leverage RS.

We use the term report to refer to the web-based or saved-to-file counterpart of a standard paper-oriented report. For example, an organization may want to give its customers an option to generate various reports online—an Order History report, for instance. Web reporting has traditionally been difficult to implement. Even more difficult has been exporting reports to different file formats. RS solve both problems elegantly, for two reasons. First, out-of-the-box RS is web-enabled. Second, most popular export formats are natively supported.

1.1.1 Why do we need RS?

Ironically, despite the important role that reporting plays in today’s enterprise, creating and distributing reports have been traditionally painstaking and laborious chores. To understand why we need RS, let’s analyze the reporting problem space.

Table 1.1 lists some of the most pressing issues surrounding the reporting arena and how RS addresses them.

Table 1.1 How Microsoft RS deals with the reporting problem space

Reporting Need How RS addresses it?
Report authoring can be labor intensive. By using the powerful Report Designer, you can author reports as easily as you can with Microsoft Access.
Centralized report management is needed. RS enables you to save your reports in a single report repository.
Reports need to be distributed to various destinations. RS supports both on-demand and subscription-based reporting. Reports can be requested on-demand by Win-Form and web-based applications. Alternatively, reports can be distributed to a list of subscribers.
Reports often need to be exported in different electronic formats. RS supports many popular export formats out of the box.
Proprietary nature of reporting tools doesn’t allow you to extend them. RS has a flexible architecture that allows you to extend RS capabilities by writing custom code.
Reports need to be secured. RS offers a comprehensive security model that administrators can leverage to enforce secured access to reports by assigning users to roles. When the default Windows-based authentication is not a good fit, it can be replaced with custom security implementations.
Enterprise reporting solutions can be costly. To minimize cost, RS is bundled and licensed with SQL Server. If you have a licensed copy of SQL Server 2000, you may run RS on the same server for no additional license fee.

Depending on your particular situation you may find other compelling reasons to target RS as your reporting platform of choice. We revisit the RS features throughout this chapter.

Supported report types

Your reporting requirements may call for authoring various types of reports that differ in complexity. For example, your users may request that a large report include a document map for easy navigation. RS lets you design a variety of report types, as listed in table 1.2.

Table 1.2 RS supports various report types

Report Type Purpose Example
Tabular Displays data in a table format with a fixed number or rows and columns. Excel-type reports
Freeform Data regions are positioned arbitrarily on the page by the report author. Invoice-invoice details report
Chart Presents data graphically. Employee performance chart
Crosstab (matrix) Data is rotated to present row data as columns. A report that shows products on rows and time on columns
Drilldown Includes expandable sections. A company performance crosstab report where product can be expanded by category and brand
Drillthrough Generated from clicking on a hyper-link. Customer Order History with hyperlinks on the order identifier to show the order details report
Interactive Includes interactive features, such as document maps, hyperlinks, visible-on-demand sections, and so forth. Adobe Acrobat.type reports with document maps on the left side

Although most popular reporting tools support many of the report types shown in table 1.2, RS makes the report-authoring process as easy as working with Microsoft Access reporting functionality. For example, report authors can drag and drop items to define the report’s appearance.

Now that we understand what RS is, let’s see how it fits in the Microsoft BI vision.

1.1.2 How is RS implemented?

Microsoft released version 1.0 of RS at the beginning of 2004 as an add-on to Microsoft SQL Server 2000. At a very high level, RS can be defined as a server-based platform for authoring, managing, and distributing reports. We discuss the RS architecture in more detail in a moment. For now, note that RS is integrated with and requires several other Microsoft products, including:

  • Windows 2000 or above as a server operating system
  • Microsoft SQL Server 2000 (with Service Pack 3a) and above
  • Internet Information Server (IIS) 5.0 or above
  • .NET Framework 1.1
  • Visual Studio .NET 2003 for report authoring and testing

For more information about installing RS, please refer to appendix A.

RS editions

To address different user needs, RS is available in several editions, as you can see by looking at table 1.3.

Table 1.3 RS supports editions to meet various reporting needs

Edition Choose when…
Standard You need to install RS on a single computer. The Standard edition doesn’t support clustered deployment to load-balance multiple RS instances.
Enterprise You need all RS features, including load balancing.
Developer You have to integrate RS with client applications or extend its capabilities by writing .NET code. The Developer edition supports the same feature set as the Enterprise edition, but it is for use as a test and development system, not as a production server.
Evaluation You need to evaluate RS. The Evaluation edition expires after 120 days.

For more information about how the RS editions differ, refer to the product documentation or the “Reporting Services Features Comparison” section in the RS official website at

For information about RS licensing requirements, visit the “How to License Reporting Services” page at

1.1.3 RS and the Microsoft BI platform

RS is positioned as an integral part of Microsoft’s business intelligence (BI) platform. This platform is a multiproduct offering whose goal is to address the most common data management and analysis challenges that many organizations face every day, such as analyzing vast volumes of data, trend discovery, data management, and of course, comprehensive reporting.

During the RS official launch presentation on January 27, 2004, Paul Flessner, Microsoft senior vice president of Enterprise Services, outlined the place of RS in the Microsoft BI platform offering, as shown in figure 1.1.

Table 1.4 outlines the purpose of the major building blocks within the Microsoft BI platform.

Figure 1.1 The Microsoft BI platform consists of several products layered on top of the SQL Server database engine and addresses various data management and reporting needs.

Most of you have probably used more than one of these products in the past to solve your data management and analysis needs. Indeed, most of them have been around for a while. What was missing was a product for authoring, managing, and generating reports that could be easily integrated with all types of applications. RS fills the bill nicely.

Table 1.4 The key Microsoft BI platform components

Component Purpose
Microsoft SQL Server A relational database to store data
Analysis Services An analytical processing (OLAP) engine
Data Transformation Services Tools for extracting, transforming and loading data
Reporting Services Server-based reporting platform for report authoring, management and delivery
Replication Services Replicates data to heterogeneous data sources
Microsoft Office Desktop applications for data analysis and reporting
SharePoint Portal Server Business Intelligence collaboration
Visual Studio.NET A development tool to create .NET-based applications, including analytical and reporting solutions.

Having introduced you to RS, let’s take a panoramic view of its features to understand why it can be such a compelling choice for enterprise reporting.


Even in its first release, RS offers a broad array of features that can address various reporting needs:

  • Information workers can leverage RS to author both standard (“canned”) reports and reports with interactive features. Here, we use the term “standard” to refer to reports that display static data. An interesting aspect of RS is that your reports can include a variety of features that provide interactivity to users. For example, the end user can show or hide items in a report and click links that launch other reports or web pages.
  • Third-party vendors can target RS to package reports as a part of their applications. For example, if customers have RS installed, the vendor setup program can upload the report files to the Report Server. You’ll see this done in chapter 2. Note that the next version of RS is expected to include stand-alone controls for generating reports directly from report files and will not require RS to be installed.
  • Organizations can use RS to report-enable their business-to-business (B2B) or business-to-consumer (B2C) applications. For example, an organization can selectively expose some of its data in the form of reports to its business partners. You’ll see an example of a similar integration scenario in chapter 11. Let’s now get a glimpse of the RS landscape and observe some of RS’s most prominent landmarks. Don’t worry if you find you are not getting the Big Picture yet. In section 1.3, we take a closer look at the main pieces of the RS architecture.

1.2.1 Authoring features

As a report author, with RS you have several choices for creating reports. We discuss each of these options in detail in chapter 2. For now, we’d like to introduce you to the Report Designer; this will likely be the option that you will use most of the time for report authoring.

Introducing the Report Designer

Using the Report Designer graphical environment, you can create reports of different types, such as crosstab drilldown reports, like the one shown in figure 1.2.

RS doesn’t restrict your report-authoring options to static paper-oriented reports. Instead, you can make your reports more versatile and easy to use by adding interactive features, such as expandable sections, hyperlinks, and document maps. Given its tight integration with the Visual Studio. NET integrated development environment (IDE), the Report Designer provides you with access to all report design features as well as team development features, such as source code management.

About the Report Definition Language

At this point, you may be wondering what an RS-based report file looks like and how it is stored. RS saves the report as an Extensible Markup Language (XML) file that is described in a Report Definition Language schema.

Figure 1.2 With RS you can create various types of reports, including drilldown crosstab reports like this one.

DEFINITION A report definition contains report data retrieval and layout information. The report definition is described in an XML schema, called the Report Definition Language (RDL).

Saving reports as XML-based report definition files offers two main advantages:

  • It makes the report format open and extensible. Using the XML-based RDL format is beneficial for achieving interoperability among applications and vendors. Microsoft is working with other industry leaders to promote RDL as an XML-based standard for report definitions. Visit the RS official website (check the Resources section for the link) for a list of Microsoft RS partners.
  • It makes the report portable. For example, you can easily save the report to a file and upload it to another Report Server. In chapter 2 you’ll see how a third-party reporting tool leverages this feature for ad-hoc reporting.

If you use the Report Designer to create your report, its definition will be automatically generated for you. However, just as you don’t have to use Visual Studio .NET to write .NET applications, you can write the report definition using an editor of your choice, such as Notepad, or generate it programmatically (as you will see in chapter 2). Of course, the Report Designer makes authoring reports a whole lot easier. Third-party tools will most likely emerge at some point to provide alternative RDL editors.

1.2.2 Management features

RS facilitates report management by storing reports and their related items in a central report catalog. To deploy and manage a report, you need to upload it to the report catalog. When this happens, it becomes a managed report.

DEFINITIONS Throughout the rest of this book we will use the terms report catalog and report repository interchangeably to refer to the RS Configuration Database. For more information about this database, refer to section 1.3.2.

A managed report is a report that is uploaded to the report catalog.

For .NET developers, the term “managed” has nothing to do with .NET managed code, although the pattern is the same. While .NET managed code runs under the supervision of the .NET Common Language Runtime (CLR), a managed report is generated under the control of the Report Server.

You may wonder what really happens when a report is uploaded to the report catalog. At publishing time, the Report Server parses the report definition (RDL), generates a .NET assembly, and stores the assembly in the Report Configuration Database for the report. The RDL file is never used again. When the report is processed, the assembly is loaded and executed by the Report Server.

A report can include other items, such as images and data source.related information. These report-related items are also stored in the report catalog. Finally, the report catalog captures additional information, called metadata, associated with reports. For example, just as you can organize physical files in folders, RS allows you to organize reports in folders.

DEFINITION The report metadata describes additional configuration information associated with a report, such as security permissions, the parent folder, and so forth.

RS offers centralized report management that administrators will appreciate. To simplify the administration of the report catalog, RS comes with a tool called the Report Manager. The Report Manager is implemented as a web-based application, and as such it is easily accessible. This tool empowers you to manage just about any aspect of the report repository, including

  • Report information and metadata, such as the folder structure and report properties
  • Data sources from which the report will draw data
  • Report parameters (for parameterized reports)
  • Security

1.2.3 Delivery features

Reports hosted under RS can be delivered using on-demand (“pulled”) delivery or subscribed (“pushed”) delivery. The more common scenario is on-demand delivery, where the user requests the report explicitly. As a report author, you don’t have to do anything special to web-enable your report because RS does this for you once it is uploaded to the report catalog.

The “pushed” delivery option alone can justify implementing RS. This option gives end users the ability to subscribe to reports, so reports will be sent to them when a certain event is triggered—when a timing event triggers, for instance, for report subscriptions based on a schedule. As another example, a financial institution could allow its customers to opt in and subscribe to certain reports of interest, such as a monthly bank statement. Then, at the end of the month, the bank statement report could be generated and sent to users via e-mail.

We’ll discuss the report-delivery process in more detail in section 1.5.

1.2.4 Extensibility features

An important characteristic of every enterprise-oriented product, such as RS, is that it has to be easily extendable. Simply put, extensibility relates to the system’s ability to accommodate new features that are built out of old ones. One of the things I like most about RS is the extensibility features it includes by virtue of its open and flexible architecture. Developers can easily extend RS by writing .NET code in their preferred .NET language. Specifically, you can extend RS in the following areas:

  • Custom .NET code—.NET developers can enhance reports programmatically by writing .NET custom code. Chapter 6 demonstrates how you can add forecasting features to your reports by using prepackaged code in the form of .NET assemblies.
  • Data processing extensions—Out of the box, RS can connect to any data source that has an ODBC or OLE DB provider. In addition, you can write your own custom data extensions to report off other data structures, as chapter 15 illustrates.
  • Delivery extensions—Out of the box, subscribed reports can be delivered via e-mail or file share delivery extensions. Developers can write their own delivery extensions to deliver the report to other destinations, such as to web services, as you’ll learn in chapter 15.
  • Security extensions—By default, RS uses the Windows-based security model to enforce restricted access to the report catalog. If Windows-based security is not an option, you can replace it with custom security models. You’ll see an example of how this could be done in chapter 15, where we’ll implement custom authentication and authorization for Internet-oriented reporting.
  • Rendering extensions—Generating reports in other export formats than the ones supported natively can be accomplished by writing custom rendering extensions. See section 1.4.2 for more information about the supported export formats.

1.2.5 Scalability features

A scalable application responds well under increased loads. RS can scale up and out to address the high-volume reporting requirements of large organizations. It is designed from the ground up to process reports efficiently. For example, it supports several report caching options, such as report execution caching, snapshots, and report sessions, as we discuss in chapter 7.

Reporting Services Enterprise Edition supports clustered deployment, which you can use to load-balance several RS servers on multiple machines. This allows enterprise organizations with high-scalability requirements to scale out RS and provides fault tolerance. RS performance is the subject of chapter 16.

1.2.6 Security features

RS is designed to provide a secured environment from the ground up. It offers a comprehensive security model for accessing reports that leverages Windows authentication. This model maps the user Windows account or group to a role, and the role describes what permissions the user has to access items in the report catalog. Report administrators can add Windows users to predefined roles or create new ones.

Once again, when the default Windows-based security model is not a good fit, you can replace it by plugging in your own custom authentication and authorization implementations in the form of custom security extensions.

To promote trustworthy computing, RS leverages the .NET code-based security to “sandbox” custom code based on configurable security policies. We discuss the RS security model in chapter 8.

1.2.7 Deployment features

Because it is server-based, RS has zero deployment requirements for integrating with client applications. For this reason, any type of client applications can target RS, not only .NET-based applications. Because you can access RS through the two most popular web protocols, HTTP-GET and Simple Object Access Protocol (SOAP), any web-capable application can be integrated with RS, regardless of the targeted platform and development language.

DEFINITIONS The Hypertext Transfer Protocol (HTTP), on which the Internet is based, comes in two flavors: HTTP-GET and HTTP-POST. While HTTP-GET passes request parameters as a part of the URL, HTTP-POST passes them as name/value pairs inside the actual message.

Simple Object Access Protocol (SOAP) is a lightweight XML-based protocol, layered on top of HTTP, for exchanging structured and type information on the Web. In recent years, SOAP has become the industry-standard protocol for communicating with web services.

Integrating your applications with RS requires a good grasp of its architecture. The next section outlines the major RS building blocks.


An important feature of the RS architecture is that it is service-oriented as opposed to object-oriented. Don Box, a Microsoft prominent architect working on the next-generation web services, outlines the following four characteristics of a service-oriented architecture:

  • Boundaries are explicit. Cross-application communication uses explicit messaging rather than implicit method call invocation.
  • Services are autonomous. The lifetime of a service-oriented application is not controlled by its clients.
  • Services share schema and contract, not class. Service-oriented applications advertise their functionality to the outside world using XML-based schemas.
  • Service compatibility is determined based on policies. By using policies, service-oriented applications indicate which conditions must be true in order for the service to function properly.

You may have used object-oriented reporting tools in the past in which the report consumer instantiates an object instance of the report provider. A characteristic of this model is that both the report consumer and the report provider instances share the same process space. For example, to render a Microsoft Access report, you need to instantiate an object of type Access.Application. Then, you use OLE automation to instruct Access to open the report database and render the report.

You will probably agree that as useful and widespread as the object-oriented model is, it is subject to some well-known shortcomings. For example, both the consumer and provider are usually installed on the same machine. As a consequence, the reports hosted by the report provider are not easily accessible by geographically dispersed clients. For instance, only COM-capable clients can interface with Microsoft Access.

A second shortcoming involves application interdependencies. Object-oriented applications are typically deployed as a unit. All Microsoft Access clients, for example, need to have the Access type library installed locally in order to establish a reference to it.

To address these shortcomings, RS departs radically from the object-oriented paradigm. In terms of reporting, the RS service-oriented architecture offers two distinct advantages: (1) Administrators can centralize the report storage and management in one place, and (2) it promotes application consumers can request reports over standard web protocols, such as HTTP—GET and SOAP.

The RS service-oriented architecture can be better explained in the context of a three-tier application deployment view, as shown in figure 1.3.

Figure 1.3 Report consumers submit report requests to the Report Server, which queries data sources to retrieve the report data and generate the report.

The RS architecture includes the following main components:

  • The Report Server, whose main task is to generate reports
  • The Report Server Configuration Database (the report catalog), which serves as a centralized report repository
  • The Report Manager, a web-based tool for managing the report catalog and requesting reports.

Let’s explain the role of each component in more detail, starting with the Report Server.

1.3.1 The Report Server

At the heart of the RS architecture is the Report Server engine. The Report Server performs the following main tasks:

  • Handles the report requests sent by the report consumers. I will use the term “report consumer” to describe any client application that requests reports from the Report Server. Once again, this could be any application regardless of the language in which it was written or the platform it runs on.
  • Performs all chores needed to process the report, including executing and rendering the report, as we discuss in detail shortly.
  • Provides additional services, such as snapshots and report caching, authorization and security policy enforcement, session management, scheduling, and subscribed delivery.

DEFINITION We will use the term “report request” to refer to the set of input arguments that the report consumer has to pass to the Report Server to generate a report successfully. At minimum, the report request must specify the path to the report and the report name. Other arguments can be passed as report parameters, including rendering format, whether the report should include the standard toolbar, and so forth.

Looking at figure 1.3, you can see that the Report Server encompasses several components, including the Report Processor, Windows Service, and extensions. From an implementation standpoint, perhaps the best way to describe the Report Server is to say that it is implemented as a set of .NET assemblies located in the C:Program FilesMicrosoft SQL ServerMSSQLRSReportServerbin folder.

NOTE An interesting fact about the Report Server is that it is 100% written in C# code. As far as I can tell, this qualifies it as the first true .NET server. No, unfortunately the source code is not provided. Moreover, the Report Server assemblies are obfuscated to prevent reverse engineering, reuse, and abuse.

As you know, the Report Server’s main role is to generate reports. To accomplish this, the server retrieves the report definition from the report catalog, combines it with data from the data source, and generates the report.

Figure 1.3 and the product documentation indicate that the Report Processor component is responsible for report processing. The implementation details of the processor are not disclosed at the time of this writing, but most likely the majority of its functionality is encapsulated in the Microsoft.ReportingServices.Processing.dll assembly. For the remainder of this book we use the terms Report Processor and Report Server interchangeably.

Section 1.4 explains the purpose of each of the Report Server components and shows how they relate to report processing.

From an integration standpoint, perhaps the most important observation that you need to draw from figure 1.3 is that the Report Server has two web-based communication façades that expose its functionality to external clients: HTTP Handler, which accepts URL-based report requests submitted via HTTP-GET, and the Web service (shown in figure 1.3 as RS WS), which handles SOAP requests. You will see how these fagades impact the report-delivery process in section 1.5.

1.3.2 The Report Server database

When you install RS, the setup program creates the Report Server database. This database is implemented as two physical SQL Server 2000 databases: The Reporting Services Configuration Database, ReportServer, hosts the report catalog and metadata. In this section, we’ll take a closer look at each.

The Reporting Services Configuration Database

The Reporting Services Configuration Database, ReportServer, hosts the report catalog and metadata. As we mentioned earlier, in order for a report to be available to the end users, its report definition file must be uploaded (published) to the catalog.

If you open this database in the SQL Server Enterprise Manager, you will be able to deduce the purpose of most of its tables. For example, the Report Server Configuration Database keeps the catalog items in the Catalog table, the data source information in the Data-Source table, and so forth. Note that querying the report catalog directly is discouraged by Microsoft. Instead, the recommended way to access the report catalog is through the Report Server APIs. Microsoft also discourages you from making data changes directly to the catalog. The reason behind this is that Microsoft may change the catalog schema in the future but will maintain backward compatibility through the Report Server API.

As you may recall, RS can be deployed in a load-balanced cluster environment. In this deployment model, the Report Server database is shared among all nodes of the cluster.

The Reporting Services Temporary Database

The RS setup program also creates a second database, ReportServerTempDB, which is used by RS for caching purposes. For example, once the report is executed, the Report Server saves a copy of the report in the ReportServerTempDB database.

DEFINITION Report caching describes the Report Server feature of keeping the report intermediate format in the Report Server database for a certain duration.

We’ll return to the topic of report caching in chapter 7.

The Adventure Works 2000 sample database

Finally, if you install the RS samples, the setup program installs a sample database called AdventureWorks2000. This database is also used by other Microsoft products, such as Commerce Server and Notification Services.

The AdventureWorks2000 database includes a much more “realistic” sales ordering database model than the SQL Server sample databases, Northwind or Pubs. You will quickly realize this by surveying the data held in the more than 60 tables. We’ll work with this sample database in section 1.7, where you’ll have a chance to create a report using RS.

1.3.3 The Report Manager

Implemented as an ASP.NET web application, the Report Manager performs two main tasks: report management and requests for reports. You can think of the Report Manager as an application fagade that communicates with the Report Server via the Report Server APIs. From the Report Server perspective, the Report Manager is no different than any other client application.

Report management

Users familiar with SharePoint Portal Server will find the Report Manager similar to this product both in terms of user interface and purpose. As you can with SharePoint, you can use the Report Manager to create folders, upload resources, manage subscriptions, and set up security.

For example, figure 1.4 shows that I used the Report Manager to navigate to a folder AWReporter and to retrieve a list of the catalog items under this folder. You can click on a report link to run a report or access and change the report properties.

In case you’re wondering where the items shown in figure 1.4 come from, we will create them in the next few chapters when we discuss the report-authoring process.

Keep in mind that in RS you work with virtual folders. Neither the folders nor the report definition files actually exist in a file system. Instead, they exist in the Report Server Database as metadata, but they appear as folders and items when you access the Report Server through the Report Manager.

Requesting reports

Sometimes, building a reporting application might be overkill. Or small companies might not have the IT resources to do so quickly or simply cannot afford the effort. In such cases, the Report Manager can be used as a reporting tool. Users can navigate to the Report Manager portal and request reports on the spot, as figure 1.5 shows.

Even better, users can use the handy toolbar, which the Report Server generates automatically, to perform various report-related tasks, including specifying parameter values for reports that take parameters (more on this in chapter 3), paging, zooming, and exporting the report to different formats.

Figure 1.4 Users can use the Report Manager portal to generate or manage reports.

Figure 1.5 Small organizations that don’t need to create report-enabled applications can use the Report Manager to request reports. This figures shows the Employee Sales Freeform with Chart report generated in HTML.

Now that we’ve had a 100-foot view tour of the major building blocks of RS, the next installment will take a peek under its hood to see how it processes, renders, and delivers reports.

More to Come

The rest of this sample chapter will appear on our website starting April 20th.

About the Author

Teo Lachev has more than 11 years of experience designing and developing Microsoft-centered solutions. He is currently working as a technology consultant with the Enterprise Application Services practice of Hewlett-Packard. Teo is a Microsoft Certified Solution Developer and Microsoft Certified Trainer. He lives in Atlanta, GA.

About the Book

Microsoft Reporting Services in Action
By Teo Lachev

Published July 2004, Softbound, 656 pages
Published by Manning Publications Co.
ISBN ISBN 1932394222
Retail price: $49.95
Ebook price: $25.00. To purchase the ebook go to
This material is from Chapter 1 of the book.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories