Visual Studio 2005 Beta2: Reporting Services: (local/remote)

Part 1: The most interesting new feature for me

A client recently asked me to prepare to train someone on SQL Server Reporting Services for their latest project. Their latest project was a VS2005 beta2 Winforms project with another ASP.NET project involved also. When I realized that in VS2003 Reporting Services was a Business Intelligence project that was added as another project in the VS2003 Solution of many projects, I wondered how that would be handled in VS2005 since the Solution there is always one project, not multiples.

Also, SQL Server Reporting Services for VS2003 had a complex architecture that relied heavily on SQL Server 2000, so I was worried that my client’s project had decided to use SQL Server 2000 for their data. I was concerned that the support for VS2005 Reporting Services would rely on SQL Server 2005 so that we could not take advantage of this reporting capability.

What I have learned is that Reporting Services now works in two processing modes: Local and Remote. Remote is using the 5 part architecture of Reporting Services: A Winforms application for designing reports inside of Visual Studio, a Webform application for managing reports/folders/ security/caching/data, a Windows Service for running reports, 2 SQL Server Databases to hold the compiled version of the deployed reports, and finally a Webservice to allow code manipulation of the reports. Local is using nothing but elements available inside your Visual Studio application whether it be Webforms or Winforms.

I’ve liked many qualities of Reporting Services since its inception, but for some applications I didn’t want to rely on the existence of a remote server existing on my target client. Now this problem is solved as I can use it either way.

Remote still provides many services unique to its architecture as SQL Server type security, scheduled email reporting, secure reporting via public HTTP Urls, etc.

All these features work very similarly for Webforms and Winforms which is a major positive. Under the Visual Studio Toolbox, Data Section of controls, there is a ReportViewer control which may be dragged to a form. In Winforms you can Dock it to All so it takes over the form entirely with a nice tool band at the top for Paging, Zooming, Output formats, etc. In Webforms you put Width=100% and Height=100% to get the similar effect.

Part2: Creating a Local Report

Below is what the control looks like not expanded to 100% in ASP.NET.

Figure 1 – The ASP.NET version of ReportViewer Control in context.

On the upper right of the control, see the small smart tag arrowhead pointing right? That is a fast way of setting the crucial properties to get the report running. Also note the DataSources tab under the Toolbox tab on the left of the image. The steps for creating and running a report local are:

1) Drag a ReportViewer control onto your form.

2) Create a new Report (via smart tag or using Ctrl-Shft-A and selecting Report as added type).

3) Create a Datasource via the Data Sources tab’s visual designer.

4) Drag fields from your Datasource into the Header &/or Table Cells of your new report.

5) Use the smart tag of the ReportViewer control to select the report if you didn’t use it to create the new report.

6) Set the form as the startup form, and run as Local mode is the default.

If you want to run in Remote Mode using reports published to SQL Server, set ProcessingMode to Remote via the dropdown and set the location of the report with a url.

(See the pertinent properties below)

Figure 2 – Properties relating to Local versus Remote reporting

These reports have many advantages as discussed in an earlier article: http://aspalliance.com/articleViewer.aspx?aId=531&pId=1

The above 6 steps can be completed in 60 seconds for a simple 1 to many table based report that requires no code to be supplied by you the developer. The new Reporting Services has become even more valuable now to me as a reporting alternative.