Editor's Note: The Following MVP Monday post is by Data Platform Development: Training MVP William Vaughn
What’s this all about?
2012 marks the 40th year that I’ve been working with data. Along the way I’ve (had to) write COBOL, 360 Assembly Language, BASIC, C, Visual Basic and Visual Basic.NET programs to produce reports. Each time I had to learn a new language it meant I had to learn a new set of report development tools. I can say with some certainty that the technology created to generate reports from RDL report definitions is the easiest I’ve had to learn and use.
How does Reporting Services Work?
Most developers who have to create reports should have discovered the ability of Microsoft Reporting Services to host and manage a catalog of RDL reports. These reports can be built in a variety of ways—the most popular being the Business Intelligence Development Studio (BIDS) tools or Report Builder. But what many developers have not discovered is that this same (well, almost the same) RDL can be leveraged to render reports using the ReportViewer control.
Let’s make a quick review of how RDL is processed so you’ll understand where the ReportViewer control can help build report-rich applications. First, you’ll need an RDL report. As I said, you can use BIDS to create a report which is persisted during development as an RDL extension file. Once it’s deployed to the Reporting Services report catalog, it’s encrypted and protected using a sophisticated rights-management scheme. Included in the RDL are all of the details needed to
- Open the connection—including providing hard-coded credentials or instructions to use SSPI authentication.
- Define any user-provided report parameters—including providing default values, acceptable values and parameter datatype constraints.
- Generate any logic-initialized report parameters.
- Define additional property or code expressions.
- Run the queries needed to return report data using the parameters defined.
- Define the report layout—including sorting, grouping, page-breaks, and any report data filtering specifications.
Once the RDL is defined, the hosted Reporting Services engine uses the RDL to render the report by:
- Opening the connection to the data source(s)—including dealing with (well, almost) connection issues.
- Generating the user parameter UI dialogs and capturing the values.
- Merge the report data into the report—this includes executing any expressions imbedded in the RDL.
- Generate custom charts, maps or special report layouts like matrix reports.
- Automatically handle data retrieval to help improve performance as the user interactively scrolls through the report.
What Reporting Services Can’t Deliver
Over the years report developers been asking Microsoft to make a number of changes to the report processors used to render the reports to further simplify their jobs. While some progress has been made, even the Denali versions of RDL still don’t provide:
- Anything in the way of a programmable report parameter user interface including the ability to build a report-parameter “report control” to customize how report parameters are displayed and captured. This also includes the basic inability to toggle parameter visibility in expressions.
- The ability to shield users from errors that inevitably pop up (literally) when things go wrong as reports are processed.
- The ability to capture user “click” events as they navigate through the reports. While we’ve had programmable “Action” operations, there are far more interesting events to capture as I’ll discuss in a minute.
- The ability to generate reports from non-supported data sources including Microsoft’s own SQL Server Compact Edition, custom data structures and Web Services (without having to write a custom data source extension).
- The ability to manage complex Visual Basic code classes in the same BIDS/Visual Studio solution. Currently, BIDS does not support the ability to create even simple Visual Basic code classes for inclusion in reports or for generating external report-referenced DLLs.
The ReportViewer Control to the Rescue
Thankfully, the ReportViewer control has the ability to handle all of these thorny (and common) issues quite nicely, but before I get started let’s visit one sticky reality: Each version of Reporting Services (including Denali) supports a unique report processor capable of interpreting a single version of RDL. So far, there are 2003, 2005, 2008 and 2010 report processors in existence. Each is capable of rendering its corresponding version of RDL. Unless Denali (SQL Server 2012) creates another version of RDL (which it might) that means you’ll need a ReportViewer that matches one of these versions.
That’s the rub. Until Denali, the ReportViewer was one generation behind BIDS. That is, the ReportViewer that shipped with Visual Studio 2008 would only (locally) process 2005 RDL. Visual Studio 2010 would only work with 2008 RDL. The Denali version of the ReportViewer control is purported to work with the current (2010?) version of RDL. In any case, the ReportViewer control can also use its built-in Server class to render any version of RDL but you revert back to the limitations described above.
So, why is the ReportViewer control better? First, consider how the ReportViewer’s report processor is different. Check out Figure 1. Note that unlike the Reporting Services hosted report processor, the ReportViewer in “local” mode does not handle any of the data retrieval tasks at all. These are all up to your code. Local mode means the RDLc file is accessed directly by the application either from a local file or one available via URL. This also means the RDLc file is a bit different. It has its DataSources reconfigured to ensure the names match up with the report layout behind the scenes.
Figure 1: The ReportViewer's report processor
With the ReportViewer, you have the flexibility to:
- Generate the parameter UI any way you like. This means you can show, hide, format and configure the parameter UI in code. This gives you infinite flexibility when it comes to populating pick lists—perhaps from a local data cache or code class. In the (simple) example in Figure 2, I’ve created a custom toolbar that helps provide an alternative to the inflexible UI generated by Reporting Services when using server-rendered reports.
Figure 2: Custom Parameter management UI
- Generate reports from any conceivable data source. All the ReportViewer needs is any structure that supports iBindingList. This means you can pass an array, a DataTable or almost anything you want. This also means you can open a connection to some third-party or custom database—even a SQL Server Compact Edition database you’ve generated with (or without) the Local Data Cache feature in Visual Studio. This also gives you the option of handling exceptions in any manner you choose. You decide what to do if the database is busy or unavailable or the user credentials don’t permit access to the data.
- Capture a host of events as the report is processed. This includes events that fires when items are clicked (DrillThrough, Click and others) or when exceptions occur (ReportError).
While I don’t have a lot of room left to get into expressions (that’s in another blog entry), consider that expressions can play a major role in the usability and performance of your reports—both developer performance (how fast you can create and maintain reports) and report performance (how quickly the report can return useful information).
If you have Visual Studio already installed on your development system, you can create BIDS report projects that fully support inclusion of Visual Basic class modules that can be incorporated in the report Code property or for externally referenced DLLs. Add to that the ability to create application test harnesses to make sure these functions and constants are working. Of course when working with ReportViewer control projects you also have the same capability in the report/application solutions. No, the expressions must all be in Visual Basic—no C# here unless it’s an externally referenced DLL.
I discuss the ReportViewer control in depth and illustrate a number of innovative features and a way to generate application client-picker user interfaces just using RDLc reports in my webinars held monthly by Progressive Tech Conferences. See http://betav.com/blog/billva and search for “Progressive” for more information. There’s also a long chapter on the ReportViewer in my “Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition)”.
Author's Bio
William Vaughn is a 40-year veteran of the computer industry including 14 years at Microsoft. He’s the author of a dozen works of what he calls “technical fiction” including “Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition)” published by Addison Wesley. His company has also published his new novel “The Owl Wrangler” available on Kindle and print-on-demand from Amazon. Over the last few years he’s focused on Reporting Services and gives monthly webinars on the subject for Progressive Business Technology. See http://betav.com/blog/billva and http://theowlwrangler.com.
MVP Mondays
The MVP Monday Series is created by Melissa Travers. In this series we work to provide readers with a guest post from an MVP every Monday. Melissa is a Community Program Manager for Dynamics, Excel, Office 365, Platforms and SharePoint in the United States. She has been working with MVPs since her early days as Microsoft Exchange Support Engineer when MVPs would answer all the questions in the old newsgroups before she could get to them.