Visual Studio 2005 Reporting

Microsoft's Visual Studio team realized that the developer community wanted a better alternative to the complexity of Crystal Report and something more sophisticated than the Visual Basic 6.0 report control paradigm. Visual Studio's 2005 ReportViewer is the result. Basically, the ReportViewer control comes in two flavors: Windows Forms and ASP.NET. The control itself is essentially the same control developers used in Visual Studio 2003 when they previewed reports in the Report Designer and the same control used when the SQL Server Reporting Services Report Manager renders a report. As shown in the architectural diagram in Figure 14.4, the ReportViewer control encompasses many of the features of the Reporting Services server-side engine directly on the client. It includes a "report processor" that interprets the RDLC report definition, processes the report parameters, and renders the report to a variety of user-selectable formats. It's capable of running in "local mode," where, unlike the server-based Reporting Services paradigm, the ReportViewer does not take on the task of managing connections or running parameter-based queries, nor does it prompt for query or report parameters. In "remote" mode, the ReportViewer merely hosts the report-centric Parameters collection, addresses a remote Reporting Services report, and renders itincluding any parameter prompts as defined by the server-side RDL report definition. Neither mode takes on the responsibility of handling the report querythat's up to your code in the local mode or the data processing extension in remote mode.

Figure 14.4. Visual Studio's ReportViewer control in "Local" mode.

As you'll discover later in this chapter, parameter management is of critical importance. I'll discuss query, local report, and remote report parameter management, as well as how and when to prompt for parameters, pass them to the ReportViewer, and use parameters to focus, tune, and customize your reports.

While the Visual Studio development tools and report support tools are far fewer, thinner, and cheaper, there is nothing to stop you from implementing your own "report server" and providing much of this "missing" functionality (or, at least, the parts you need) using your own code. Something else you don't need when building Visual Studio reports: SQL Server. Nope, you don't need any version of SQL Server to fully utilize the Visual Studio 2005 reporting tools, designers, and ReportViewer control. You'll also discover that the tools I've already discussed that are used to build strongly typed TableAdapters can be used to generate report data. And yes, the ADO.NET code you've been working with for years can also be used to generate untyped DataTable instances to be passed to the ReportViewer.

Virtually all versions of SQL Server 2005 include Reporting Services, including SQL Express. The only version that doesn't support it is the new SQL Everywhere SKU. This means you might want to leverage the more interactive report-authoring tools afforded by the BIDS SKUs.

Yes, you can use the ReportViewer control to reference and render SQL Server 2005 Reporting Services deployed reports, and in some cases, this makes a lot of sense. Sometimes, you need to integrate a report into an application and, after capturing the parameters, simply request the parameterized report from Reporting Services. That's something that the BIDS tools don't really help you with. When users access Reporting Services reports via a browser, they are free to change the URL to alter the parameters or choose other reports or report rendering options, and cause other mischief (subject to the limitations of the security settings). This means you might have to create an application specifically designed to capture parameters and execute reportsthat's right up Visual Studio 2005's report tool's alley.

Tip

You'll need to convert all Reporting Services 2000 Reports before using them with Visual Studio 2005.

While you might miss the BIDS report project, connection, dataset, and design wizards that spit out templated reports after a few minutes of drag-and-drop development work, you'll also find that you quickly outgrow the wizards. You'll soon learn to build your own customized report templates based on your company's report format guidelines. Given how easy it is to add templates to Visual Studio 2005, this should not be a big issue. In addition, I'll show you how to leverage reports developed with any RDL tool (including the BIDS Report Designer) and launch them from your custom Windows Forms or ASP.NET application.

Before I get started, let's touch on a quick technical point: The RDL files created by the Visual Studio 2005 Report template and populated and managed by the Visual Studio 2005 Report Designer generate an RDLC extension file. Yes, this is a variation on the XML RDL-formatted files used in Reporting Servicesthe same, but different enough that they (sadly) can't just be interchanged. One would think that a future version would just deal with the differencesat least, with an import wizard. I'll step through the process of passing these files (with some modification) among Visual Studio 2005, BIDS projects, and SQL Server 2005 Reporting Services.