Review: SQL Server 2000 Reporting Services

SQL Server 2000 Reporting Services
licensed with SQL Server
Redmond, Washington

I don't know whether they were fed up with third-party alternatives, in need of new features, or what, but the Microsoft SQL Server team has jumped into the Web-based reporting fray. SQL Server 2000 Reporting Services is an add-on for current SQL Server installations (it will be packaged with new copies of SQL Server later this year). Before you decide whether it makes sense to look at Reporting Services for your application, you need to understand the licensing just a bit (see the licensing FAQ page for the details). Reporting Services is licensed with SQL Server. That means if you want to run the whole thing on a server where you already have a SQL Server installation, you're covered. If you want to split it off to a different server to save load, you're in for the full cost of SQL Server, which is substantial. And the Reporting Services database will not work with MSDE; you need the full product.

To design a report for Reporting Services, you use a special Visual Studio .NET project (so count a Visual Studio .NET license into your pricing comparison). The designer is reasonably simple, and handles expressions and grouping with no particular problem. You can also import reports from Access databases, but there are some limits on this (not all Access features are supported, and you can't import just a single report), which limits the usefulness of this feature. After you create the report, by whatever means, you publish it to a report server for general use.

After reports are published, you can use Report Manager (a Web-based application) to manage them. You can change data sources (from a test server to a live server, for example), edit security credentials, and schedule reports to be refreshed on a schedule rather than run on demand. You can also create subscriptions that automatically deliver updated reports via e-mail or file share, which is a nice touch. Splitting out this sort of DBA report task from normal report development fits well with the way many SQL Server shops are organized.

There are a bunch of extensibility points built into the whole thing. You can, for example, manage a report server via SOAP, or create custom rendering components for your reports using .NET. Compared with some other products this is a very open architecture. On the output side, although the reports start in a browser they're not trapped there; it's easy to get TIFF, PDF, Excel, XML, HTML with Office Web Components, or other useful formats from any report.

Overall, it's pretty easy to get started using Reporting Services (I had a mystery failure to install on my first test box, but that one was old and full of cruft; it installed easily on a fresh computer). And the overall approach does offer a lot of power and scalability. But the licensing requirements will give some shops pause, and there are the usual version 1 fit-and-finish issues here (I found two errors in the first tutorial, for example). But if you're doing reporting from SQL Server data, you ought to grab a copy of the evaluation version and have a look.

About the Author

Mike Gunderloy has been developing software for a quarter-century now, and writing about it for nearly as long. He walked away from a .NET development career in 2006 and has been a happy Rails user ever since. Mike blogs at A Fresh Cup.


Upcoming Events


Sign up for our newsletter.

Terms and Privacy Policy consent

I agree to this site's Privacy Policy.