In archeology, the Rosetta stone was the key that solved the mysteries of Egyptian hieroglyphics. I believe that with the release of Microsoft SQL Server 2000 Reporting Services, code-named Rosetta, Microsoft gives organizations the key they need to unlock the secrets of enterprise data and unleash the power hidden within.
Looking retrospectively, Microsoft’s reporting strategy has been confusing, at least for me. Microsoft Access debuted in the early 90s with a powerful report designer that made desktop reporting child’s play.
Enterprise developers, however, have not been that lucky. The lack of comprehensive native reporting capabilities continues even today in the .NET framework. True, some progress has been made with the advent of print-related controls, such as PrintDocument, PrintPreviewControl, and so on, but still, dealing with the GDI+ (Graphics Device Interface) API is usually the last thing a developer wants to tackle when creating the next line-of-business application. For reasons such as these, report-enabling Microsoft-centric solutions has been traditionally regarded as a tedious chore.
To address this problem, many of us defected to third-party tools. Others chose to fill the void with homegrown, customized solutions. While these solutions address particular needs, they can also be costly, time-consuming, and difficult to implement.
I remember with nostalgia a project that I worked on about five years ago. It called for developing a reporting solution for a major Fortune 100 company. I implemented the solution as a server-based framework, following a design pattern similar to the one discussed in chapter 13. I used Microsoft Access as a reporting tool to generate reports and save them as snapshot files. Once the report was ready, the Report Server would e-mail it back to the user or send the user a link to the snapshot file.
Implementing this solution was a lot of fun, but it took a significant development effort. I wouldn’t have had to do all of this if I had had Reporting Services back then. Instead of implementing a homegrown solution, I could have used RS to report-enable the applications.
For this reason, I was very excited when I heard about Reporting Services in late 2003. Finally, there was an easy way to report-enable different types of applications. Subsequently, I was involved in a project where I was able to confirm to myself that, indeed, RS was the reporting platform I had been dreaming about for years.
To share my enthusiasm I decided to write a book about Reporting Services. While I contemplated what the book’s scope would be, it dawned on me that I could bring the most value by following my heart and approaching Reporting Services from a developer’s point of view. I put myself in a position that many developers could relate to. Here I am, a developer, consultant, and architect, who is tasked with adding reporting features to a given application. How would I go about this?
To answer this question, my book takes a solution-oriented approach, and more than half of it is devoted to integrating different types of applications with RS. As you read this book, you will discover a common pattern. It starts by discussing the requirements and design goals of a given reporting scenario. Then it discusses the implementation choices, and finally it explains how the solution is implemented.
I firmly believe that a technical book should go beyond rehashing the product documentation. I tried my best to follow this path and take up where the RS documentation (which, by the way, is excellent) leaves off. For this reason, my book should be used in conjunction with it. When you read the book, you will notice that sometimes, when I believe I can’t explain things any better, I refer you to the product documentation.
Microsoft Reporting Services in Action is written for report authors, administrators, and developers who need a detailed and practical guide to the functionality provided by RS. In the first half, report authors will master the skills they need to create versatile reports. Administrators will learn the ropes of managing and securing the report environment.
The second half of the book is primarily aimed at intermediate-to-advanced .NET developers who are planning to leverage RS to add reporting capabilities to their Windows Forms or web-based applications. However, because of the service-oriented architecture of Reporting Services, the book will also benefit developers who target other platforms but want to integrate their applications with RS.
Microsoft SQL Server 2000 Reporting Services is a great piece of technology. With RS, report authors can create reports as easily as you would do it in Microsoft Access. Make no mistake, though. RS is a sophisticated server-based platform, and its feature set goes well beyond that of a desktop reporting tool. To use RS effectively, you need to have a solid grasp of how it works and how it can be integrated with different types of client applications. I hope this book makes this endeavor easier.