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.
End of Article
