Microsoft SQL Server 2000 Reporting Services
- What Is Microsoft SQL Server 2000 Reporting Services?
- Reporting Services: The Main Components
- Writing Reports: The Report Designer
- The Report Server
- The Report Manager
- Versions of Reporting Services
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
This chapter puts Microsoft SQL Server 2000 Reporting Services in context. You'll learn about its architecture and its place in the world and get a brief overview of its features and functionality. This is an important chapter because it helps you understand why Reporting Services is more than just an alternative (or supplement) to Crystal Reports and how it can make your life easier.
We know you're chomping at the bit to get started—and perhaps you've already installed the software, snooped around, and tried out a report or two. Hopefully you've extracted a copy of the symmetric encryption key and have the backup off-site, along with the backup file password. Yes? Good. Now we're ready to dispel any prejudices or misconceptions your explorations have generated.
Security is (or should be) very important to you; at least we know your boss is concerned with security. All along the way, we'll show you how to secure your data and reports in ways that the documentation doesn't mention or only touches upon. We'll discuss encryption and topics that seem pretty far removed from "reporting," but without these protections, you might as well post reports exposing your company secrets on the 20-foot newsreader board in Times Square.
We've spent quite a bit of time creating audio-annotated screen capture demonstrations of aspects of Reporting Services. You'll find these demos on the accompanying DVD. We call these Guide me! videos. If you need help on a section, look for the Guide me! icon in the margin.
What Is Microsoft SQL Server 2000 Reporting Services?
It is difficult to contain my genuine heartfelt enthusiasm and appreciation when I attempt to succinctly encapsulate what Microsoft SQL Server 2000 Reporting Services is and provides. Just bear in mind that I don't do marketing double speak; I am British, and we are the modest world masters of understatement.
—Peter
At long last, developers have a brand-new server-based reporting solution from Microsoft built from the ground up, almost completely but not entirely in .NET managed code. Without being too enthusiastic, we can say that Reporting Services enables extremely straightforward, centrally managed, rapidly developed, easily extended, scalable, secure, fixed as well as interactive, proactive as well as passive database reporting to a variety of (extensible) output formats, from any database or data source (and not just SQL Server) whose learning curve is hardly a curve; it's almost flat. <Whew!> Best of all, it's free! Well, let's qualify that statement a little: it's included with the SQL Server Standard or better license at no additional cost.
Not having taken the Microsoft red pill, [1] we can freely draw comparisons to other reporting products on the market. One of the first that undoubtedly flashes into everyone's minds is Crystal Reports. In contrast to Crystal Reports, Reporting Services is a product that Microsoft definitely got right from the outset. We see a new age dawning of assault on Crystal practitioners. Stand by to be assimilated—resistance is futile.
Okay, if you are at the pinnacle of pushing Crystal to its functional feature limits, you may well find that Crystal offers additional functionality over Microsoft Reporting Services, even if it's expensive and awkward to learn and use. However, we think that the vast majority of developers and power users in the market want reporting that's easy to use, learn, and develop with. Microsoft Reporting Services certainly delivers that.
I first saw what Microsoft was hatching with Reporting Services (code-named Rosetta) in February 2003. Back then it was planned as a release feature of the next version of SQL Server (code-named Yukon). After we and the other folks privileged with this sneak preview had relocated the shreds of our blown-off socks, we gave our feedback and petitioned to have Reporting Services released now, as in right now, with the current version of SQL Server 2000. Microsoft appeared to take that feedback to heart, and in June 2003 it was publicly announced at the TechEd Conference in Dallas: Rosetta for SQL Server 2000 would indeed be released at the end of 2003. We're both glad that Rosetta was untied from Yukon because we don't expect this innovative version of SQL Server to appear for another year (or so).
—Peter
What Is the Source of the Report Data?
Before we go any further, we want to reinforce the message that although the product name includes the moniker "SQL Server 2000" as in "Microsoft SQL Server 2000 Reporting Services," in fact SQL Server 2000 is required only as the catalog repository for the deployed (managed) reports and their metadata, and not necessarily as the only data source that those reports can be based on.
In fact, right out of the box Reporting Services includes built-in support to generate reports from a number of data sources through what the Reporting Services folks call Data Processing extensions. Think of them as another form of .NET Data Providers; they're based on the same technology. Data is extracted from SQL Server and Oracle as well as any other database management system (DBMS) that can be accessed via either OLE DB providers or ODBC drivers using Data Processing extensions. This means that most commercial data stores are accessible because there are managed .NET Data Providers as well as OLE DB or ODBC drivers for virtually every serious data source. These providers are available from Microsoft or from the DBMS manufacturers and third-party data provider vendors such as DataDirect (and others).
Reporting Services is designed with an open architecture. No, Microsoft does not publish the source code, [2] but under the covers, Reporting Services' Data Processing extensions utilize a subset of easily understood .NET Data Provider interfaces. If you can get or write a .NET Data Provider for a custom data source (something that's moderately easy), Reporting Services can connect to and generate reports on that custom data source. [3] We'll discuss this in more detail in Chapter 13 where we'll show you our implementation to report on the Windows system event logs.