Creating Subtotals in a Matrix in SSRS (2005/2008)

This is a quick look at how to create and use subtotals in your Matrix objects.

Subtotals 101

SQL Server Reporting Services makes it relatively easy to add totals to your columns and rows in a matrix object. In short, it’s as easy as right-click>Subtotal. Seriously, that’s it. Well, unless you want to format them, but that’s another issue entirely (an not quite as straight forward).

Let’s do this step-by-step :

  1. Open or create a new SSRS project
  2. Add a report item to your project.
  3. Add a dataset
  4. Add a matrix object
  5. Configure matrix to desired specification
  6. Add totals to outer groups by right-clicking the outer column/row group for which you require the subtotals and select subtotal.
  7. Add subtotals for inner groups by right-clicking the inner column/row group for which you require the subtotals and select subtotal.
  8. Tidy up by hiding the inner group line items initially – by right-clicking the inner group and selecting Properties>Visibility and then setting the properties accordingly.

Here’s a quick 2 minute screen cast of how to create subtotals in a Matrix object in SSRS 2005. It illustrates creating row group Totals & subtotals, but applies to column groups as well:

Here’s a link to another version if you are having any trouble: http://www.screencast.com/t/OGE1MmI4

Custom Visibility Toggling SSRS 2008

A while back I wrote a post about how to toggle the visibility of rows/columns in tables/matrices for SSRS 2005. In the comments of that article someone asked how this was done in SSRS 2008. The short answer was that the method is the same. However, setting all the properties can be confusing as their whereabouts is a little different. Hopefully this post will clear things up.

Let’s do this by way of example:

I created a project with a single report. The Data source is AdventureWorks2008 and we are looking at Total Sales figures by Year & Month (keep it simple right?). I have set up a matrix object and added the required fields and set subtotals for Month & Year. See Fig 1. below:

Objective: Enable Toggling of the Month group, using the Year Group as the Toggle Item

At this point I want to point out two key areas, as this is where we will be concentrating our efforts:

  1. The Row/Column Groups section at the bottom of the designer
  2. The Visibility Properties at the bottom right corner (Last item in the Properties list – but only when an object is selected)

Now, select the drop-down arrow for the Month Row group (See Fig 2.), choose Properties and then select the Visibility tab.

The objective is to enable toggling of the Month rows in the Matrix. We could choose to Show or Hide the Month rows when the report is initially run, or to make this decision based on an expression. Using an expression will determine which rows are expanded and which are collapsed when the report is run initially. I have chosen to use an expression:

=IIF(Fields!YEAR.value=2001, False, True)

This says that if the Year group value is ‘2001’ then show the Month Sales Total values (‘Expanded’), else Hide the Month Sales Total values (‘Collapsed’). See Fig 3. below:

Also note (in Fig 3. above) that I have set the YEAR cell as the Toggle Item. We’ll configure this next.

Once you have set the above properties go back to the designer and highlight the YEAR cell in order to view its properties. These should be on the bottom right, otherwise right-click the cell to bring up the properties window. Find the Visibility > InitialToggleState property and set it using the following Expression:

=IIF(Fields!YEAR.Value = 2001, True, False)

This says that if the Year group value is ‘2001’ then show the toggle icon as ‘Expanded’ (True), else show it as ‘Collapsed’ (False). This allows us to ensure that we are in sync with the expression we used to set the initial visibility of the Month rows. Fig 4. shows the end result of all this hard work:

The Visibility Properties

Understanding what each of the three visibility properties does will help to use them effectively.

Hidden – Can be set to either ‘True’ or ‘False’. This can be done by selecting True or False from the drop down, or by using an expression to set either of those values after evaluating a condition. True equates to the object being hidden and False to the object being shown (tricky eh?).

InitialToggleState – This is only applicable if the object that you have selected can toggle the visibility of other objects. It refers to the state of the toggle icon and can either be ‘Collapsed’ (‘+’) or ‘Expanded’ (‘-‘). As explained by way of example above, setting this to ‘’True’ sets the icon to the ‘Expanded’ state, and False to the ‘Collapsed’ state.

ToggleItem – Use this property to set the object that will enable the user to toggle the visibility of another item. In the example above, I have chosen YEAR as my toggle item for the Month Group.

Beware the Gremlins

You need to be aware of setting properties for the right objects or groups, or you may find that your report does not display correctly:

Fig 4. shows what happens when you set the Visibility properties for the Month & Data CELLS in the report instead of the Month Group properties. Setting the Month Group visibility properties means that you won’t get that nasty white space, and there’s no need to set the visibility of the cells (in this instance).

I have placed the example project in a nice little zip file for all you folks that might want such a thing.

Download Reports (.RDL) files for editing (SSRS 2005)

If you ever happen to be in a situation were you do not have access to or have ‘misplaced’ the SSRS report files (.rdl) and you need to edit one (or more) of the reports on your server, there is an easy way to download the .rdl files.

Follow these easy steps:

  1. Open SQL Server Management Studio,
  2. Log on to the Reporting Services Instance that contains the reports you are looking for
  3. Browser through the directory structure to the report that needs to be updated
  4. Right-click the report and choose Edit…
  5. Now follow the prompts to save the file to a destination of your choice
  6. Open BIDS & create a new project/solution
  7. Import the (previously) saved .rdl file into your SSRS project.
  8. Edit away to your hearts content….

 

I’m not going to ask why you don’t have access to or have misplaced the files in the first place (No source code management? Seriously?). I am sure there are a myriad of reasons that you can come up with. This post merely provides a quick way to recover your files and continue edits/updates that may be required.

The DatePart() Function in SSRS

Using the DatePart() Function in SSRS can be tricky, even at the best of times. I have pulled my hair out too often trying to remember what syntax should be used, so have resorted to writing down all my findings. This is so that you don’t have to go through the same agony & frustration as I did, as well as for my own benefit (my memory is shot…)

What it does: Returns an Integer containing the specified part of a given date

Syntax: DatePart(interval, date[,firstdayofweek[,firstweekofyear]])

There are two ways to use this function:

  • Using the DateInterval collection
  • Using a string expression
 
Using the DateInterval Collection

Let’s start with an example:

To return the current month: =DatePart(DateInterval.Month, Today())

Now, in the expression builder (in BIDS), it will look like there’s something the matter with what we have just written:

You can ignore this, the expression will work. An important point to note when using the DateInterval collection, is that you must use a date that is of type Datetime. If you use a string representation of a date (“2009/11/13”), then you’ll need to convert this to Datetime using CDate(“2009/11/13”) before the expression will work. Thus:

This will work:  =DatePart(DateInterval.Month, CDate(“2009/11/13”))

This won’t:  = DatePart(DateInterval.Month, “2009/11/13”)

When you use the DatePart function to identify the day of the week you can specify what the First Day Of The Week is (defaults to Sunday if this is not specified). You can do this by accessing the FirstDayOfWeek collection. Example – To Return the day of the week, specifying Monday as the first day of the week:

DatePart(DateInterval.Weekday, CDate(“2009/11/13”), FirstDayOfWeek.Monday) returns 5 (Friday)

All the possibilities for using the DatePart() function with the DateInterval Collection:

The following table shows all the possibilities for the DatePart Function using the DateInterval collection. All expressions use a Parameter called MyDate (type = Datetime), which has a value of “2009/11/13 12:34:23”

Expression Result
DatePart(DateInterval.Second, Parameters!MyDate.Value) 23
DatePart(DateInterval.Minute, Parameters!MyDate.Value) 34
DatePart(DateInterval.Hour, Parameters!MyDate.Value) 12
DatePart(DateInterval.Weekday, Parameters!MyDate.Value, FirstDayOfWeek.Monday) 5
DatePart(DateInterval.Day, Parameters!MyDate.Value) 13
DatePart(DateInterval.DayOfYear, Parameters!MyDate.Value) 317
DatePart(DateInterval.WeekOfYear, Parameters!MyDate.Value) 46
DatePart(DateInterval.Month, Parameters!MyDate.Value) 11
DatePart(DateInterval.Quarter, Parameters!MyDate.Value) 4
DatePart(DateInterval.Year, Parameters!MyDate.Value) 2009

 

Using a String Expression

Again, let’s start with an example:

To return the current month:  =DatePart(“m”, Today())

Using a String expression for your interval enables you to use a date that is of datatype String:

=DatePart(“m”, “2009/11/13”)

All the possibilities for using the DatePart() function with a String Expression:

As noted previously, using a string expression for the interval allows you to use a date value that is of the String datatype. You can of course use a Datetime value if you wish to.

This table shows all the possibilities for the DatePart function using a String Expression for the interval. All expressions use a Parameter called MyDate (type = String), which has a value of “2009/11/13 12:34:23”

Date Part Expression Result
Second DatePart(“s”, Parameters!MyDate.Value) 23
Minute DatePart(“n”, Parameters!MyDate.Value) 34
Hours DatePart(“h”, Parameters!MyDate.Value) 12
Day of Week DatePart(“w”, Parameters!MyDate.Value, FirstDayOfWeek.Monday) 5
Day of Month DatePart(“d”, Parameters!MyDate.Value) 13
Day of Year DatePart(“y”, Parameters!MyDate.Value) 317
Week of Year DatePart(“ww”, Parameters!MyDate.Value) 46
Month DatePart(“m”, Parameters!MyDate.Value) 11
Quarter DatePart(“q”, Parameters!MyDate.Value) 4
Year DatePart(“yyyy”, Parameters!MyDate.Value) 2009

 

Is there a preferred method?

Ul
timately, no. At the end of the day, all the results are the same. What is my preference? I use the DateInterval collection, mainly becuase I like that fact that you can’t get confused about which date part you are using (w/ww, y/yyyy, n….). It’s very clear to anyone who is reading the code that (for example) DateInterval.WeekOfYear refers to the week of the year and nothing else. It also forces you to use a Datetime Value, which safeguards against invalid dates (sort of).

I hope this clears things up a little!

Troubleshooting SSRS Data Driven Subscriptions (SS 2005)

Let’s just assume that…

You’ve created your data driven subscription (File share) for your reporting services report, and everything is as it should be. The subscribers table has been created, populated and correctly mapped to the required fields in the subscription (FileName, Path, Format, Parameters, etc), the schedule is set. And then you test your subscription.

The Error Message Status

The schedule has run and you find this very helpful error message status beside you subscription in Report Manager. Scratching your head you dive into the Error & Event logs searching (in vain) for those few lines that will shed some light on the question “Why did those 2 errors occur?” Nothing.

Found ‘em!

Hidden away in its own folder are the Reporting Services Log Files:

SQL Sever 2005 –> *C:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting Services\LogFiles  

SQL Server 2008R2 –> *C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\LogFiles

*These may be different depending on your installation

More specifically, you’ll need to look at the ReportServerService__mm_dd_yyyy_hh__mm_ss.log files. These files will list, among other things, any errors encountered in your Data Driven Subscriptions. Here’s mine:

From this I could deduce that there was a problem with the filename that was being used for one of the reports. Once I had reviewed all the filenames being used and had updated those that contained the special characters (2 of them), the subscription ran without a hitch. Problem solved.

So the bottom line here is, if you have any issues with you reports look in the reporting services log file.