Archive for month: August, 2007

One of the major themes in SSRS 2008 is scalability. A significant effort will be made to ensure that SSRS scales well with large reports. Why is this needed? Recall that in SSRS 2005 (and 2000), report processing is instance-based. This means that the report engine would process the entire report as a snapshot, including textbox values, styles, etc. As a result, SSRS 2005 reports are memory-bound. In general, the memory consumed by SSRS 2005 is proportional to the size of the report. The bigger the report, the more memory it would take. Therefore, large reports won’t scale well.

In contrast, the SSRS 2008 processing engine processes the reports on-demand. It pre-computes and saves only certain invariants, such as grouping, sorting, filtering, and aggregates. However, textbox values are calculated on-demand every time the containing page is rendered. To test this, drop a textbox on the report and set its value to =Now(). In SSRS 2005, when you page back and forth, the textbox value will not change. In contrast, in SSRS 2008, the textbox value would change to the most current date each time the containing page is rendered.

As a result of the on-demand processing model, the in-memory presentation of the report is much smaller. If you want to learn more about the engine improvements in Katmai, I highly recommend the Chris Baldwin’s excellent Enterprise Scale Report Engine webcast. At this point, you may wonder how much memory the new engine could save. I tested print preview for an existing 1,270 report with the old and new engine and here are the results.

As you can see, in this case the new engine takes 70% less memory which is a pretty remarkable improvement. This is not to encourage you to author such monster reports of course. However, if you have to, for audit, regulatory, or whatever reasons, the new engine should be able to help.

As I mentioned in a previous blog, SQL Server 2008 will probably include an RDL Object Model. This is great news for developers who generate report definitions programmatically. No more custom RDL object models as the one I talked about during my TechEd presentation. The early incarnation of the promised object model is included in the July CTP (CTP4) and resides in the \Microsoft SQL Server\MSSQL.3\Reporting Services\ReportServer\bin\Microsoft.ReportingServices.RdlObjectModel.dll assembly.

DISCLAIMER Before rejoicing too much, recall the usual disclaimer that everything is in a flux and a subject to change. Although here, the RDL Object Model may very well disappear in the final bits.

Note that I disclaimed myself let me introduce you to the RDL Object Model (don’t try to find it in BOL; long live .NET Reflector!).

using System;

using System.IO;

using Microsoft.ReportingServices.RdlObjectModel;

using Microsoft.ReportingServices.RdlObjectModel.Serialization;

namespace RDL

{

class Program

{

static void Main(string[] args)

{

string idef = @”C:\Reports\Sales by Product.rdl”; // input report in RDL 2008 format

string odef = @”C:\Reports\Sales by Product1.rdl”; // output report in RDL 2008 format

Report report = null;

RdlSerializer serializer;

if (!File.Exists(idef)) return;

// deserialize from disk

using (FileStream fs = File.OpenRead(idef))

{

serializer = new RdlSerializer();

report = serializer.Deserialize(fs);

}

report.Author = “Teo Lachev”;

report.Description = “RDL Object Demo”;

// TODO: use and abuse RDL as you wish

// serialize to disk

using (FileStream os = new FileStream(odef, FileMode.Create))

{

serializer.Serialize(os, report);

}

}

}

}

As you can see, using the RDL Object Model is simple. Once you add the reference to (\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services\ReportServer\bin\Microsoft.ReportingServices.RdlObjectModel.dll, you are work with RDL in object-oriented way. You use the RDLSerializer class to load a report definition (Deserialize method) or get RDL from a report object (Serialize method). Both methods support various overloads to read/write from/to stream, XmlReader, and more. I load an existing Sales by Product report into the Report object using the RDLSerializer.Deserialize() method. Note that it must be saved in the SSRS 2008 format. You need to use the stand-alone Report Designer to do so. If you use the SSRS 2005 format you will get an exception because you will need to upgrade to RDL 2008 (see next paragraph about how to upgrade RDL). From there, I write the report object back to disk as a Sales by Product1.rdl file. What could be easier? Compare this with XmlDom programming and you will start seeing how the RDL Object Model can make your life easier.

There are also methods for upgrading RDL to SSRS 2008 (Microsoft.ReportingServices.ReportProcessing.RDLUpgrader .UpgradeToCurrent) and SSRS 2005 (Microsoft.ReportingServices.ReportProcessing.RDLUpgrader .UpgradeTo2005) formats.

An RDL object model has been long due on my wish list. Kudos to the SSRS team for materializing it.

In case you’ve missed it, the SSRS team has started a SQL Server Katmai Reporting Services forum and eagerly awaits your feedback.

The need for a stand-alone Report Designer is real. True, developers, including myself, enjoyed the VS.NET Report Designer. But novice users were overwhelmed with the complexity of the VS.NET IDE environment. In addition, not all IT shops rejoiced over the idea to install VS.NET or BIDS just to author reports. Enters the SSRS 2008 stand-alone report designer.

As its name suggests, you run this designer completely outside VS.NET. In fact, in CTP4, VS.NET has not been yet integrated with the new designer (it still uses the RS 2005 designer). Therefore, to get the new RDL enhancements in CTP 4, such as tablix, you need to use the stand-alone report designer.

Note that stand-alone doesn’t mean embeddable. While a future release make this possible, it is unlikely that you will be able to embed the SSRS 2008 designer in custom .NET application.

You launch the stand-alone report designer from the Report Designer Preview link in the Reporting Services program group. As you would immediately see, its UI resembles the Report Builder UI. There are a few welcome enhancements. First, there is a new Data Window which shows the Build-in Fields, Parameters, Images, and Datasets all in one place. Next, the Group Task Panes shows conveniently the row and column groups and minimizes the steps required to set up a new group. With SSRS 2005, you had to create a new row in the table region and configure it using the Group properties dialog box. Moving forward, you can just drag a dataset field below a given group in the pane to create a new subgroup.

Clicking inside a textbox shows a Field Picker icon. When you click on it, you will see a dropdown of the dataset fields and conveniently pick the field instead of dragging it from the dataset fields to the textbox. While we are on this subject, you will notice that for the sake of brevity the Report Designer replaces the field expressions with tokens (enclosed with square brackets), such as [Sum(Sales)] instead of =Sum(Fields!Sales.Value). Clicking inside the textbox gives you access to the actual expression.

There is also a new Zoom pane which lets you zoom the report in and out. As you would expect from an early build, many features are not hooked up yet. For example, report preview requires uploading the report to the server.

Oh, yes… the thing in the middle is the new Tablix region but this is a topic for another post.