SharePoint List Data Extension

R2 brings several SharePoint enhancements, including:

  • Support for multiple SharePoint zones – Previously, SSRS supported access from SharePoint URLs in the default zone, as I explained before.
  • Support for the SharePoint Universal Logging service – Reporting Services introduced a new server interface called IRSSetUserToken. When this interface is implemented, the report server calls the UserToken Set property on this interface and passes the SharePoint user token to the data extension.
  • Scripting with the rs utility – The rs utility now supports servers configured in SharePoint integrated mode. This lets you create scripts that automate management tasks that target report servers in SharePoint mode.
  • New SharePoint List Data Extension – Lets you report from SharePoint lists

The last on the list, the new SharePoint List data extension, probably picked up your interest and deserves more explanation. Previously, if you had to use the XML Data Provider to call the SharePoint web service if you wanted to report off SharePoint lists. The new extension simplifies this by supporting SharePoint lists natively. But before you get too excited about it, I have to dampen your enthusiasm by mentioning two limitations:

  1. The extension supports querying a single list only.
  2. It doesn’t support folders if the list organizes items in folders.

The SharePoint List data extension is supported with both modes – native and SharePoint integrated. It supports Windows SharePoint Services 3.0 and 2010, as well as MOSS. Next, I’ll demonstrate the SharePoint List extension by setting up a dataset that retrieves items from the Issues list of a SharePoint site. The SharePoint list extension is available both in the BIDS Report Designer and Report Builder 3.0. For the purposes of this demo, I’ll use the BIDS Report Designer.

Configuring the data source

Start by setting up the data source as you would normally do when you author a report.

  1. Set up a data source that uses the Microsoft SharePoint List provider.
  2. In the Connection String field, enter the URL of the SharePoint site that has the list you want to query.
  3. Switch to the Credentials tab and select the Use Windows Authentication option. Click OK to close the Data Source Properties dialog.


Configuring the dataset

Once the data source is in place, the next steps will be to set up a dataset. The SharePoint List data extension supports a graphical query designer that lets you select and filter a list.

  1. Add a new dataset that uses the data source you’ve just created. On the Dataset Properties, click the Query Designer button.

Report Designer loads the graphical query designer. The SharePoint Lists pane shows all lists in the library. You can check a list to get all fields of the list or select individual fields. You can hover on a field to see additional properties as tooltips, such as Name, Identifier, Field Type and Hidden properties.

You can also filter the list. In this case, the Issues list is associated with a My Issues view. Since I don’t have any issues assigned to me, I had to overwrite the list filter by supplying a non-empty query filter. For demo purposes, I decided to set up a filter where the Title column contains the word “parameter” and the Modified date is after 10/1/2009.


  1. Click the Run Query button to execute the query and see the data and the OK button to close the Query Designer and generate the dataset.

In case you are curious what the actual query looks like, click the Edit As Text query button. If you want to get all fields, the query can omit the ViewFields element.

<RSSharePointList xmlns:xsi=”” xmlns:xsd=””>



<FieldRef Name=”ID” />

<FieldRef Name=”ContentType” />

. . .






<FieldRef Name=”Title” />

<Value Type=”Text”>parameter</Value>



<FieldRef Name=”Modified” />

<Value Type=”DateTime”>2009-10-01T00:00:00</Value>






The SharePoint List data extension is a new R2 feature that simplifies the process of authoring reports from SharePoint lists. Although it doesn’t support all features of third-party data extensions for SharePoint, it’s a welcome enhancement that lets you retrieve and filter items from a single SharePoint list.

Report Parts

The major new R2 feature that debuts in CTP 3 (November CTP) of SQL Server 2008 R2 Reporting Services is report parts. A report part is a fragment of a report definition that you can publish to the report server to facilitate best practices and reuse. Just like a developer can refactor and share some piece of code, the report author can re-factor a portion of a report and publish it to the server so that end users can use it as it-is. The following report items can be published as report parts:

  • Charts
  • Gauges
  • Images
  • Maps
  • Parameters
  • Rectangles
  • Tables
  • Matrices
  • Lists

A notable exception to this list is page headers and footers which are probably the most likely candidates for reuse but at this point they didn’t make the list. It’s important to note that if a data region uses a report-specific dataset (not a shared dataset), publishing the region as a report part will publish its dependent dataset. Report parts can best understood by example, so let’s walk through the workflow of publishing, using, and changing a report part.

Publishing report parts

You can use the BIDS Report Designer or Report Builder 3.0 to publish a report part. The following steps assume you use Report Designer. Let’s say I decided that the tablix with sparklines, which I discussed in a previous blog, is a darn good and it should be promoted as a published report part that other users could enjoy for educational or other purposes.

  1. Start by setting the server folder where report parts will be published on deploy. In the project properties, set the TargetReportPartFolder (a new deployment setting) to the name of the server folder, such as Report Parts, or a SharePoint library URL for SharePoint integrated mode.
  2. With the report open in design mode, expand the Report main menu and click Publish Report Parts. If you use Report Builder 3.0, click the Report Builder 3.0 button (the round button in the topmost left area) and select Publish Report Parts.
  3. The Publish Report Parts dialog box shows the items on the report that are supported as report parts. Check the Tablix report item.
  4. You can rename a report part by double-clicking its name and typing the new name in place. Click the arrow next to it to expand the Tablix section. Enter a description, such as “A table with sparklines” and click OK to close the dialog box.


5.  So far, you have configured which items will be promoted to report parts but you haven’t actually published them. To do so, you need to publish the containing report. In Solution Explorer, right-click the report and click Publish.

At this point, you should see messages in the BIDS Output Window informing that the report and the report parts you defined are being published.

Deploying report part ‘Tablix’ to ‘/Report Parts’…

Deploying report parts complete — 1 succeeded, 0 failed, 0 skipped

6.   Open Report Manager (or SharePoint) and navigate to the Report Parts folder. You should see the Tablix report part.


If you go to its properties and download its definition, you will see that the file name has an *.rsc extension and that the report part is represented by a ComponentItem element in RDL. Notice also that the report part definition includes all datasets that report part uses. Once the report part is published, you can manage it just like you can manage a published report. For example, you can change its name, description, or security settings.

Using report parts

End users can consume published report parts. Notice that I said “end users” because more than likely this will be the most common scenario. In fact, the BIDS Report Designer doesn’t support referencing report parts, only publishing them. The Report Builder 3.0 has been extended to support this feature.


  1. Open Report Builder 3.0 and create a blank report.
  2. Click the Report Builder 3.0 button, click Options and verify that the report server URL is set.
  3. Click the Report Part Gallery tab of the Properties window. Click the Search button to show all report parts that you have access to.
  4. Select the Tablix report part and notice that Report Builder 3.0 shows its properties below.
  5. Drag the Tablix report part and drop it on the report canvas.

Report Builder 3.0 adds the tablix region, the dataset is bound to and report parameters. From here, the report part takes a life of its own. You can make changes to the report as needed including changes to the report part elements. The layout changes you make are not reflected to the published part. If you want to re-publish the changed report part, you can click the Report Builder button and click Publish Report Parts. This will prompt you if you want to re-publish with default settings or review and make changes which will bring you to the Publish Report Parts dialog box.

Changing report parts

The original report part author or another user which appropriate permissions can make changes and re-publish a report part. End users can check if a report part has changed and choose to accept or not the changes. To do this, they have to poll the server for updates. Currently, there is no way for the server to push the changes to all reports who consume the report part in order to force the changes.


  1. In Report Designer or Report Builder 3.0, open the report that has the Tablix report part. Make changes to the tablix region and deploy the report to re-publish the report part.
  2. In Report Builder 3.0, open a report that uses that report part.
  3. Click the Report Builder 3.0 button and click Check for Updates. Notice that Report Builder 3.0 detects the changes and displays a message that it has found one changed part.
  4. Click the View Updates button to see what report parts have changed. In the Update Report Parts dialog box, select the Tablix report part and click the Update button to refresh it.

Report Builder 3.0 replaces the tablix region the published version. However, Report Builder 3.0 keeps the existing dataset and parameters, even if they are not changed, and appends new datasets and parameters each time the part is refreshed. So, if you have a dataset called Main, refreshing a part will add a new dataset called Main2 and bind the refreshed part to Main2.

Report parts are a new feature of SSRS R2. They promote consistency and reuse by letting you re-factor sections of a report and make them available for public consumption.

Sparklines and Data Bars

Besides indicators, R2 adds sparklines and data bars to the arsenal of data visualization features. Sparklines are small graphics embedded in a context of words, numbers, and images. They help end users visualize simple trends. You could implement sparklines and simple data bars in the previous versions of Reporting Services but you had to go through many steps to strip down the chart or gauge regions. R2 makes the process much simpler. Let’s see what it takes to author a sparkline report with R2 that is similar to the Sparklines report included in my book source code. [View:]


This report helps the user visualize the performance of the Adventure Works sales persons. For each person, the report shows the employee’s trend based on the reseller sales made over four quarters and his performance ratio which is defined as the actual sales made by the employee divided by his sales quota. The report gets the data from the Adventure Works 2008 Analysis Services cube.

Configuring Sparklines

In Reporting Services, a sparkline is a scaled-down chart region. Configuring a sparkline takes a few simple steps.

1. Right-click on a tablix cell and click Insert ð Sparkline.

2. In the Select Sparkline Type dialog box that follows, select the Line sparkline type.



3.  Double-click the sparkline region to open the Chart Data panel which is another new design feature in R2.


4.  Click the plus sign in the Values pane and select the Reseller_Sales_Amount to configure the sparkline series.

5.  Click the plus sign in the Category Groups pane to add the Category_Quarter_of_Year field to configure the category groups.

That’s it! I’ve made a few more minor adjustments to finalize the sparkline, such as removing the chart border, setting the chart background for the “green bar” effect and increasing the line width.

Configuring Data Bars

To demonstrate data bars, I implemented the employee’s performance ratio using a data bar region. Similar to a sparkline, a data bar is a simplified chart.

  1. Right-click on a cell and click Insert ð Data Bar. I actually, configured the data bar outside tablix first by embedding it inside the rectangle and copying and pasting it inside the tablix cell. I did that to make the bar narrower so it doesn’t occupy the entire cell height.
  2. On the Select Data Bar Type, leave the default Bar type selected.


3.  In the Chart Data panel, click the plus sign in the Value pane to add the PerformanceRatio field and set its aggregation function to Avg.


That’s pretty much it to set up the initial data bar although I had to go through a few more steps to configure the bar labels and appearance.

Although not revolutionary features, Indicators, sparklines and data bars will save you time when you need to enhance your report with simple graphics. Sean Boon from the Reporting Services team has written an interesting blog post that demonstrates more sparkline features to implement a win-loss sparkline.


Often, reports need to show images that represent discrete values, such as an image that shows a KPI status. Previously, you didn’t have another option but to use images that are dynamically changed based on the field value. Indicators, a new R2 feature, make this much simpler. In Reporting Services, an indicator is a simplified gauge region that lets you associate images with states. Although you can use indicators as stand-alone regions, you would typically nest them in a tablix, as the following report [View:] demonstrates. The right-most column of this report shows the Gross Margin KPI status as an indicator.


Authoring this report takes a few simple steps:

  1. Add a dataset that requests the Status property of the Financial Gross Profit Margin KPI from the Adventure Works 2008 Analysis Services cube grouped by Year and Quarter.
  2. Use a tablix region to show the KPI status with Year and Quarter row groups.
  3. Right-click the cell in an empty column and click Insert ð Indicator.
  4. In the Select Indicator Type dialog that follows, select the indicator type. In this case, I chose the default directional type.


  1. Once the indicator region is added to tablix, right-click on it and click Indicator Properties. In the Indicator Properties dialog box, select the Value and States tab.
  2. Since in this case I display numeric values and not percentages, change the States Measurement Unit drop-down list to Numeric.


    By default, the default directional indicator lets you defined three states, as shown below. However, you can add or delete states and use custom images if needed. In my case, I defined a range from -1 to 0.-99 for underperformance, 0 – 0.99 as acceptable performance, and 1 as good performance.




    Indicators are simple but very useful enhancement to Reporting Services. They lets you visualize discrete values on reports.

Pagination and Rendering Enhancements

R2 brings more control over pagination and rendering. A question that pops every now and then on the discussion list is how to name Excel worksheets for each instance of a row group. This scenario wasn’t supported before R2. In R2, there are addition page break options, as shown in the screenshot below. One of them is PageName.


In this case, I set the PageName property of the ProductCategory row group to the Category field. Then, I set up the BreakLocation of the ProductCategory row group to break when the product category changes. The screenshot below shows what the exported to Excel report looks like. As you can see, each worksheet is now named. If the row group spills on the next page, a new worksheet is added with the same name.


Another welcome enhancement is the ability to reset page numbering. Suppose you have a master report that includes a subreport and you want to reset the page numbering before the subreport is rendered. This is another commonly requested scenario which wasn’t supported before R2. In the screenshot below, I have a report package that includes two subreports. I want to reset the page number after the first subreport renders. Since the subreport region doesn’t have page break properties, I enclosed the first subreport in a rectangle and set the rectangle PageBreak ð BreakLocation to End and PageBreak ð ResetPageNumber to True. In the page footer, I added Globals!PageNumber of Globals!OverallTotalPages. Since you can reset the page number, the RS team has added also OverallPageNumber and OverallTotalPages built-in fields to the Globals collection. Given this setup, the report will increase the page number for each page in the Company Sales 2008 report. Once Company Sales 2008 has rendered, the server will reset the page number but it will show the overall number of pages.


Notice that there is also a Disabled page break property. Suppose that when exported to other formats you want your report to break on each row group instance but when exported to Excel you want the entire report to export to a single worksheet. R2 has added two additional built-in fields to the Globals collection, RenderFormat.Name and RenderFormat.IsInteractive, that lets you support such scenarios. In this case, I had to define the following expression for the PageBreak ð Disabled property:

=Iif(Globals!RenderFormat.Name=“EXCEL”, True, False)

If the user exports the report to Excel, the expression turns on the Disabled property and no page breaks are generated. However, if the user exports the report to another format, the report breaks on each instance of the row group.

Finally, to round up the rendering enhancements, you have now the option to rotate text 270 degrees as shown in the report below. This can be easily achieved by setting the textbox WritingMode property to Rotate270. You probably would want to set also TextAlign to Center and VerticalAlign to Middle.


Shared Datasets

When the Reporting Service team asked my opinion about shared datasets, a new feature in the forthcoming SQL Server Reporting Services R2, I was somewhat skeptical. I preferred them to focus on more important in my mind features, such as the ability to join datasets at report level. But the more I look at the way shared datasets got implemented, the more real-life scenarios I think may benefit from this enhancement.

Think of a shared dataset a hybrid between a shared data source and report execution. Similar to a shared data source, a shared dataset is a report dataset that can be managed independently and shared among reports. A shared dataset must use a shared data source. The shared datasets can be parameterized and reports that use it can pass parameters to it. Similar to report executions, a shared dataset can also be cached and refreshed on a schedule. In my opinion, there are two main scenarios where shared datasets can be useful:

  • Easier maintenance – Suppose you have a dataset that you can re-use across reports, such as a dataset that populates the parameter available values. You want all reports to reuse the dataset and pick up the dataset query changes automatically.
  • Improved report performance – You may have query that takes very long to execute. You want to execute the query in an unattended mode, such as outside working hours, perhaps for different set of parameters, and cache the dataset for a specific duration.

Creating Shared Datasets

Creating a shared dataset is easy. Both BIDS Report Designer and Report Builder 3.0 are capable of creating shared datasets. In Report Designer, you right-click on the new Shared Datasets folder in Solution Explorer, and click Add New Dataset. In Report Builder 3.0, you click the Create Dataset option on the main Create Report or Dataset popup screen.

You can easily convert a report-specific dataset to a shared dataset. Just right-click any dataset in Report Data Window and click Convert to Shared Dataset. Consequently, Report Designer will re-factor the dataset as a shared and it will add its definition to as an *.rsd file to the Shared Datasets folder in Solution Explorer. In the screenshot below, I have converted the EmployeeSalesDetails dataset in the Employee Sales Summary 2008 report to a shared dataset. Notice that the EmployeeSalesDetails dataset reference inside the report has a special icon.


As I mentioned in a previous post, the project properties dialog get enhanced to support new deployment settings that are specific to shared datasets. Specifically, the OverwriteDatasets setting specifies if the shared dataset definition will overwritten on deployment if it exists and the TargetDatasetFolder specified in which folder the dataset definitions will be deployed to.

Once the dataset is configured as shared, you can set up its properties, which include the dataset query, fields, and filters. Then, you can configure the dataset reference inside the report to pass parameters to the shared dataset or to have its own filters. This is similar to how to you configure a subreport. What if you want to use row-level security and you need to pass the user identify to the dataset query (User!UserID)? Just add a query parameter to the shared dataset, such as LoginID, and configure the dataset reference inside the report to pass User!UserID as a parameter to the shared dataset.


Managing Shared Datasets

Once the shared dataset is deployed, it can be managed just like any other published item using Report Manager or SharePoint. Common management tasks include setting the data source reference, caching, and security. The most interesting of these is caching. Just like report executions, you can cache a shared dataset. When a shared dataset is configured for caching, the report server will cache a dataset copy for each parameter combination. The same restrictions apply as with caching report executions. Specifically, the data source cannot use Windows Security or Prompt for Credentials authentication options. You can configure cache expiration options. For example, if data latency of 30 minutes is acceptable, you can configure the dataset cache to expire in 30 minutes.


Let’s say you a dataset query that takes very long to execute. You can set up a cache refresh plan to warm up the dataset cache on a set schedule. Cache refresh plans are also a new R2 feature. Previously, you pre-execute reports by creating a subscription using the NULL delivery provider. Moving to R2, you don’t need to use the NULL provider anymore and you can refresh shared datasets independently from reports. In the process of setting up a cache refresh plan, you need to specify an item-specific or shared schedule and default values for each parameter, just like you would do with snapshot caching or subscriptions.


As you can see, shared datasets can help you implement some interesting scenarios when you need to reduce the management effort or improve the report performance.

Not All Calculated Members Are Born Equal

An interesting issue popped up yesterday regarding the calculated member syntax. I had to multiply negative amounts in a financial cube for certain account categories that had negative amounts. The cube also had a Many:Many relationship between financial accounts and account groups which may be related to the issue. So, I had the following scope assignment:

CURRENTCUBE.[Multiplier] /* Old Style*/

AS [Financial Account].[Financial Account Hierarchy].CurrentMember.Properties(“Multiplier”, TYPED),




[Financial Account].[Financial Account Hierarchy].Members


this = [Financial Account].[Financial Account Hierarchy].CurrentMember * [Measures].[Multiplier];


The Multiplier calculated member returns the Multiplier property of the current account member, which could be 1 or -1 (if the account has to be negated). Then, the scope assignment overwrites all measures for the current member. As simple as it is, the assignment didn’t work and the account amounts didn’t get converted although the Multiplier calculated member would return the correct number. I stripped out the entire cube script to only these two script definitions but I couldn’t make it to work. After some research, I came to this interesting discussion between Chris Webb and Read Jacobsen, which made me think that the issue probably has something to do with the solve order of the calculated member. As it turned out, the new style has a higher pass so the following fixed the issue:

HIDDEN [Multiplier] = [Financial Account].[Financial Account Hierarchy].CurrentMember.Properties(“Multiplier”, TYPED); /* New Style*/

As Chris suggested, I tend to believe that it’s a bug especially given the fact that I’ve recently logged another nasty calculated member-related issue, where scope assignments would produce wrong results if the calculated members with the old style definitions are hidden.

Aggregates of Aggregates

Aggregates of aggregates is a new feature in SQL Server R2 Reporting Services. It can be better understood by the sample Aggregates.rdl report ([View:]). It shows sales grouped by year and quarter. The Year group subtotals use the Sum aggregation function to sum the quarter sales. The report footer total averages the year subtotals.


Prior to R2, authoring such a report would require dividing the total sales by the number of quarters, which you can obtain by using the CountRows function. You cannot just use the Avg function in the footer as the Bad Sales measure shows:


If you do so, the Avg function would operate on the detail rows (all quarter rows) and it would produce 2,258,360. R2 lets you nest aggregate functions. The Sales footer total uses the following expression:

=Avg(Sum(Fields!Internet_Sales_Amount.Value, “Year”))

In this case, the Average function operates over the aggregated year subtotals. Note that not all aggregate functions can be nested. For example, you cannot define an aggregate over the Aggregate, RunningValue and Previous functions.

Where is the SSAS 2008 Book?

Readers have been asking about a revised edition of my Applied Microsoft Analysis Services book for version 2008. First of all, I’d like to thank all my readers who bought and liked the book. This book has been a great success and it really exceeded my expectations in any way! It has great reviews on Amazon and it has sold over 10,000 copies to date, which is not a bad sales record for a technical book. I am still supporting my readers on the book discussion list and more than likely will continue doing so for foreseeable future. At the same time, I decided not to write a revision for SSAS 2008 or R2 for two main reasons:

  1. I just need a break from book writing. It took me several months to write the Applied Microsoft SQL Server 2008 Reporting Services and BI toolkit. I am not ready to start a new book and … face a divorce. Seriously, writing books is not easy and it takes a lot of time away from the family. And I just can’t write small.
  2. Version 2008 of Analysis Services has been an incremental and stabilization release. The theme was “don’t rock the boat” since the boat was rocked big time in SSAS 2005, which was essentially a re-write of Analysis Services from ground up. The major 2008 enhancements were in the area of performance and manageability. So, hardly enough material to write a revision from a feature standpoint although I definitely have plenty of real-life experience to contribute. So, Applied Microsoft Analysis Services 2005 is still not outdated and I hope you won’t go wrong reading it. Speaking of this book, since it looks like the demand for it waned in the past months (everyone jumped on the 2008 bandwagon, and this is what you should do) I’m not planning a new print. Instead, I lowered the price of the e-book version to $29.95, so the book is still available in e-book format if you decide to buy it.

Although I am not planning a new SSAS book anytime soon, I am committed to Analysis Services, which I like very much and use heavily in real-life projects. Looking forward, I am planning a new SSAS revision for SQL Server 11, which is next major release of SQL Server after R2. Meanwhile, I offer an Analysis Services 2008 training class if you are looking for instructor-led online training.

What Analysis Services 2008 books would I recommend?

Novice User

  1. Professional Microsoft SQL Server Analysis Services 2008 with MDX – written by members of the SSAS team
  2. Microsoft SQL Server 2008 Analysis Services Step by Step – a good introduction to Analysis Services
  3. Microsoft SQL Server 2008 MDX Step by Step – I’ve heard good things about this book from my co-workers who used it to learn MDX basics
  4. MCTS Self-Paced Training Kit (Exam 70-448): Microsoft SQL Server 2008 Business Intelligence Development and Maintenance – if you plan to take the 70-448 BI exam, we wrote this book for you. My contribution was the SSAS chapters.

Experienced User

  1. Expert Cube Development with Microsoft SQL Server 2008 Analysis Services – You won’t go wrong with the fellow MVPs: Marco Russo, Alberto Ferrari, and Chris Webb. I reviewed this book here.
  2. Microsoft SQL Server 2008 Analysis Services – if you really want to get under the hood, you won’t get disappointed by the folks who implemented Analysis Services
  3. MDX Solutions: With Microsoft SQL Server Analysis Services 2005 and Hyperion Essbase – Bring your MDX knowledge to the next level.

Speaking of books and writing, I have an exciting announcement which I’ll make soon in another blog. Stay tuned…