Direct Reports : Tips

Marquee Moon (Field References in Page Headers and Footers)

bwelcker — Wed, 20 Jun 2007 09:57:00 GMT

One of the questions that I get often is about putting database fields in their SSRS report page header and/or footer. Note that putting fields in the page header and footer is not the same as putting a data region in these sections. Because of the impact...(read more)

At the End of Paths Taken (Modifying Where Clause when All Parameter Values are Selected)

bwelcker — Sat, 19 May 2007 23:32:00 GMT

With the return of “Select All” in Service Pack 2, all multi-value parameters allow the user to pick all of the available values. But what if you want to remove the predicate from your WHERE clause instead of generating a long set of values in the IN predicate?

You can accomplish this is via an expression-based query and an internal parameter.

First, create a second parameter in your report. It should be have a new name, multi-valued, use the same valid values query and the default values set to the valid values query as well. In addition, mark the "internal" flag in the parameters dialog so it is not displayed to the user.

Next, change your main report query to an conditional expression that compares the number of selected values to the number of available values (which will always be selected in the new parameter). For example:

="SELECT Hour, Month, Year, Username, Sitename, Cookie FROM dbo.GlobalIISLog " & IIF(Parameters!ComputerName.Count = Parameters!AllComputerNames.Count,"", " WHERE (sComputername IN (@ComputerName))")

I have attached a sample report that demonstrates this technique.

Wincing the Night Away (Tips for SSRS in SharePoint Mode)

bwelcker — Mon, 05 Feb 2007 00:53:00 GMT

Here is some useful information about using SSRS in SharePoint Integrated mode (included with SP2):

Installing the SharePoint Add-In

If you plan to upgrade from a previous version of the add-in, you should uninstall the previous add-in then install the new one. After installing the new one, you will need to perform the RS configuration steps in SharePoint Central Administration again.
If you have trouble with the install, take a look at the log files. In addition to the MSI install log, the Add-In also creates another log file named RS_SP_<number>.log. Both logs are found in the "<Drive>:\Documents and Settings\<User_Name>\Local Settings\Temp" folder.
There is a known issue with the naming ReportServer.<culture>.resx files that are install as part of CTP3 in each SharePoint web sites' App_GlobalResources folder. After installing CTP3 this issue manifests itself as the following errors when you try to access any SharePoint web site:

Server Error in '/' Application.
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed.

To solve this, check the following in IIS Manager for each SharePoint web site:

Explore into <Web site>\App_GlobalResources

Do you see any Reportserver.<culture>.resx files (where culture is a string like EN / FR/ CS etc.)?

If yes, then delete all Reportserver.<culture>.resx except for ReportServer.resx file.

Deploying Reports to Report Server that is in SharePoint Mode

Use the updated Report Designer that ships with SQL 2005 SP2 CTP.
Deployment paths need to change for deploying to a SharePoint Document Library with settings something like this:

TargetDataSourceFolder: http://<MyServer>/<mySharePointsite>/<my_DataSource_Folder>/
TargetReportFolder: http://<MyServer>/<mySharePointsite>/<my_Report_Folder>/
TargetServerURL: http://<MyServer>/<mySharePointsite>/

If you see a login screen when deploying reports, inspect the web.config fle of the SharePoint web site for the following entry:

<location path="_vti_bin/ReportServer/ReportServiceAuthentication.asmx">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
</location>

Make sure there is only one such entry in the web.config file. Delete any duplicates. Next retry deploying. This is a known issue in the CTP release that we are fixing for RTM.

Today! (Cleaning up Reporting Services SharePoint Add-In Setup Problems)

bwelcker — Thu, 09 Nov 2006 21:28:00 GMT

Some people have had problems during installation of the new Reporting Services Add-in for Microsoft SharePoint. If the add-in setup fails while to add the Reporting Services feature to the sites, some of your SharePoint sites will no longer work. You can tell if the custom action failed by looking for a file named RS_SP_#.log in your %temp% directory. If you have a log file there and your install failed, you will need to manually clean up your web.config files to get SharePoint up and running again.

First, you will need to locate the SharePoint virtual directories on your server. Typically these are located at c:\inetpub\wwwroot\wss\VirtualDirectories. This folder contains several folders with names which are numbers representing the ports used by your SharePoint sites. In each folder you will need to remove the following entries from the web.config file:

and

Once you remove these lines, save the file. You must do this for every web.config file under the above directory.

To get around the issue, you need to add the user who is running setup as one of the Site Collection administrators before you run the setup. You can do this though the Site Adminstration page.

This is a known issue with our CTP2 setup and has been addressed in CTP3.

End of Amnesia (Avoiding Divide By Zero Errors)

bwelcker — Tue, 26 Sep 2006 19:46:00 GMT

People often ask how to avoid divide by zero problems in their Reporting Services reports. Let's say you have a textbox that calculates profit margin via the expression:

=Fields!Price.Value / Fields!Cost.Value

This works fine unless a value in the Cost field is zero (and is not an integer or double), in which case you will get '#error' displayed in your report. This is because a divide by zero with a decimal field will throw an exception. This exception is caught by the report processing engine and #error is displayed. If you would rather have a string like "N/A" instead of #error, you might think about creating a Reporting Services expression using the IIf function:

=IIf(Fields!Cost.Value = 0, "N/A", Fields!Price.Value / Fields!Cost.Value)

But when you preview the report, you still see #error in your report. What gives?

If you take a look at the IIf function description in the Visual Basic documentation, you will see the following:

As part of preparing the argument list for the call to IIf, the Visual Basic compiler calls every function in every expression. This means that you cannot rely on a particular function not being called if the other argument is selected by Expression.

This means that even through the value for cost is zero, the error will still be generated. So how do you work around this? You have to force the expression evaluation to avoid the division with a nested IIf:

=IIf(Fields!Cost.Value = 0, "N/A", Fields!Price.Value / IIf(Fields!Cost.Value = 0, 1, Fields!Cost.Value))

The nested IIf is evaluated first so that the divide by zero can be avoided but is not used by the outer expression if it is zero.

As an interesting side note, the Arithemtic Operators topic in the Visual Basic documentation seems to say that a DivideByZeroException is thrown for dividing by anything but the Double data type. I have not found this to be the case. Try this simple application in VB:

Dim a, b As Integer
a = 1
b = 0
MsgBox (a / b)

You will get "Infinity", despite what the documentation says. Anyway, the use of the expression above in your report will ensure that you will get the desired results, no matter what data type you are using.

Alien Lanes (Logical and Physical Pagination Rules)

bwelcker — Fri, 19 Aug 2005 17:57:00 GMT

One of the things I see people getting confused about in Reporting Services is around page sizing. Not setting the correct properties can result in extra blank pages or improper paper orientation. Here are some general guidelines for setting page sizes.

The rules around page sizing depend on whether you are talking about physical pagination (used by the print control and the TIFF and PDF rendering extensions) or logical pagination (used by the HTML and GDI rendering extensions).

For rendering formats that render physical pages, set the PageHeight and PageWidth properties for the report to control the pagination. These can be set in the Report Properties dialog (available under the Report menu) along with LeftMargin, RightMargin, BottomMargin, and TopMargin.

One thing that is important to know is that setting the Body size at design time is not generally useful in controlling pagination. The body is simply the container for the collection of objects on the report. The design time size of the body represents the smallest amount of space that will be taken up by the report. However, if any objects grow as they are filled with data, the body will expand to contain them. Mostly, the body will grow taller (tables, lists, and textboxes are a few of the items that will cause vertical growth) but can also grow wider (matrices and autosized images can cause horizontal growth).

So, when does a physical page break occur? When the runtime size of the body (plus the page header and footer size, if they are defined) exceeds the specified page size (minus the margins). It's important to understand that controls on the page that don't look like they contain any information (a wide textbox) can cause a blank page to be added to the report if it exceeds the page boundaries. Page breaks can also be specified explicitly before or after instances of report items (rectangles, groups, data regions). There are also certain situations were we ignore explicit page breaks (e.g. inside subreports).

So what defines a portrait vs. landscape report? If the PageHeight is less than the PageWidth, then it is landscape, otherwise it is portrait. It is important to understand that Reporting Services has no notion of the rotation of the paper in the printer. It is up to the applications that consume the output (Acrobat reader, print control) to determine the correct printer settings to best render the specified page size.

Note that the DeviceInfo settings can be used at report rendering time to override the page sizes in the definition. This is how the client print control works when you change margins or page size. In SP2 and SQL 2005 Reporting Services, the default page sizes are extracted from the definition at publish time and written to the ReportServer database as custom properties on the report. While you can programmatically change these via the SetProperties method on the web service, they will be overwritten if the report is republished (unlike parameter and datasource information).

Logical pagination is a little bit different. In SQL 2000 Reporting Services, interactive rendering formats used the same PageHeight property to determine page breaks. Since there is no real page boundaries on web pages, it is only used as a guidelines to reduce the amount of data to put on a single page. SQL 2005 Reporting Services introduces the InteractiveHeight and InteractiveWidth properties to determine logical page breaks. Actually, InteractiveWidth is not used at all but may be in a future release. The nice thing about this is that if you don't want pagination in the web at all, you can set InteractiveHeight to 0 and the processing engine will produce your report as a single logical page.

The Excel rendering format does not explictly support pagination. The page size and margins are mapped into the Excel document for printing within Excel. For these reports, you will need to specifically include page breaks to break the report into multiple worksheets.

All Mod Cons (Multilingual Reports with AS2005)

bwelcker — Mon, 04 Jul 2005 04:46:00 GMT

Based on feedback from a couple of folks, I've decided to make my post titles a bit more descriptive. I'll still use the name of one of the albums in my music collection as the primary title but will also include a description of the actual content of the post (happy, Jason?).

Anyway, one of the cool new features of SQL 2005 Analysis Services is translations. This lets you provide language translations for both the data and the metadata in your cube. When an application connect to the server, it can provide the Locale ID (LCID) of the desired language in the connection string. If the translation is not done, it will use the default one.

To get this working, provide a parameter that allows you to select the language. You could just as easliy bind it to the User!Language global to get the language of the current users. One of the tricks is that Reporting Services uses Language names instead of LCIDs. I had to write a custom function to translate between them:

Public Function GetLCID(Name As String) As Integer
Dim CI As New System.Globalization.CultureInfo(Name)
Return CI.LCID
End Function

I first designed the report using English and then switched to use the GetLCID function in the connection string.

="Data Source=localhost;Initial Catalog=""Adventure Works DW"";Locale Identifier=" & Code.GetLCID(Parameters!Language.Value)

Unfortunately, this only works for the data, not the static text. You would need to write some additional custom expressions for the report text. But it should give you a feel for how to leverage this feature in your own reports.

Perfect From Now On (Custom Chart Legends)

bwelcker — Fri, 20 May 2005 10:51:00 GMT

While the legend built into Reporting Services charts is relatively easy to use, it lacks some of the flexibility that you might like to have. One issue is that it takes up space within the chart boundaries, making the plot area smaller as the number of series grows. So how can you get more control over the legend? Roll your own!

The trick here is to replace the legend inside the chart with a table data region beside the chart bound to the same data set. First create a custom function to return a series color based on the group value. To be consistent, the function should use a hash table to map the same value to the same color:

Private colorPalette As String() = {"Green", "Blue", "Red", "Orange", "Aqua", "Teal", "Gold", "RoyalBlue", "#A59D93", "#B8341B", "#352F26", "#F1E7D6", "#E16C56", "#CFBA9B"}
Private count As Integer = 0
Private mapping As New System.Collections.Hashtable()

Public Function GetColor(ByVal groupingValue As String) As String
If mapping.ContainsKey(groupingValue) Then
Return mapping(groupingValue)
End If
Dim c As String = colorPalette(count Mod colorPalette.Length)
count = count + 1
mapping.Add(groupingValue, c)
Return c
End Function

Create your chart and set the series value appropriately. Hide the legend in the chart properties dialog. Now create a table with with two columns and a single row grouped by the group expression used as the graph series. Set the color of the data point in the chart as well as the background color of the first column in the table to:

=Code.GetColor(Fields!Series.Value)

Thanks to Robert Bruckner for the work on this one. I have atttached a sample report using this technique using the Northwind sample database.