Leverage Reporting Services 2005 Independent of Your Database

Microsoft SQL Server 2005 consists of more than just the core database engine. With the release of SQL Server 2005 came updated components such as SQL Server Reporting Services (which I'll refer to as Reporting Services 2005). Similar to SQL Server 2005 Analysis Services, which I discussed in my last column "Get'em While They're Hot" (http://www.windowsitpro.com/sqlserver/article/articleid/48370/48370.html), Reporting Services 2005 is a standalone set of components that leverage data stored in SQL Server 2005. This distinction is important because when you're upgrading your database, you can install Reporting Services 2005 on a separate server and reference your existing databases.

Let me make myself clear: SQL Server 2005's core database features can be upgraded independently from Reporting Services 2005. Although, in theory, it's possible to transition all your databases and reporting services simultaneously, the reality is that individual applications often upgrade on slightly different schedules. Reporting Services 2005 supports this because the reports can be run against databases that are still running on SQL Server 2000. For that reason, it's advantageous to have standalone components that support services. That way, you can choose to upgrade your core database components for one application while separate servers for reporting are upgraded on their own schedule.

IT organizations often quickly see the value in upgrading the core database components because these components are typically upgraded with no significant operational impact. However, most IT organizations see components like Reporting Services as oriented more toward custom interfaces and end-user interaction, which typically have upgrade problems. Thus, IT organizations tend to put off such upgrades. But with Reporting Services 2005, migrating your report server is just as safe and easy as upgrading your database because you perform the upgrade on a backup of your production environment to verify there are no surprises in configuration.

According to Microsoft, Reporting Services 2005 has been improved in four main areas: core services, the developer experience, the end-user experience, and integration. I'm going to gloss over the core services and developer enhancements. It might seem strange to gloss over these two areas in a publication named "Developer .NET UPDATE," but the reality is that the improvements in these two areas are the types of enhancements you'd expect (or even demand) from Microsoft. Although improvements in performance and a better environment for building and testing reports are vital to the success of this release, they don't make news.

On the end-user experience front, Reporting Services 2005 has a new feature that is newsworthy. Back in 2004, Microsoft purchased a small privately held Utah company called ActiveViews. This event didn't generate much press coverage. The only publication in which I found it covered was Tech Digest (http://seattlepi.nwsource.com/business/170743_tbrf27.html). However, ActiveViews produced a popular add-on to SQL Server 2000 Reporting Services. Microsoft, which had by this time started working on most of the features for Reporting Services 2005, saw how this design tool could be leveraged. Reporting Services 2005's new Report Builder is the result of this purchase and over a year of integration and enhancements. The Report Builder provides end users with the ability to design custom reports without needing to tie up development team resources.

The Report Builder actually has two parts: the Report Builder Client, which is used by end users, and the Report Builder Model Designer, which supports the Report Builder Client. The Report Builder Client is a .NET Click Once application. In other words, it uses the same set of tools that a developer can leverage with Windows Forms 2.0 to build applications. The Report Builder Client lets end users access a predefined database model that abstracts the underlying data implementation. End users can design a report that fits their needs without involving a developer and constantly requesting changes. The ability to build an application themselves gives end users a level of satisfaction that's hard to match. They can try six or seven alternatives without waiting for their changes to be routed through the IT organization each time.

The database abstractions aren't limited to the generated views. Developers can use the Report Builder Model Designer to customize the underlying database connection strings, tables, and other database objects to better fit the model to the business. The idea is that a developer helps define the model, then end users leverage that model to create the "pretty" report.

The remaining improvements for Reporting Services 2005 lie in the area of integration. However, given space constraints, I'm going to save my discussion of these improvements for my next column. Improved integration refers to not only integration with Analysis Services and other SQL Server 2005 components but also improved integration to external products, such as Microsoft SharePoint. In the meantime, if you'd like more information about Reporting Services 2005, you can start at http://www.microsoft.com/sql/technologies/reporting/default.mspx.