As part of my standard operating procedure when demonstrating report snapshots, I point out this label, so I was rather taken aback when I didn’t see it in the demonstration I was preparing. It sort of upset my routine, and I’m rather partial to my routines. I thought perhaps I wasn’t looking in the right place and changed Report Manager from Tile View to Detail View, but no – that label was still missing. In the grand scheme of life, it’s not an earth-shattering change, but you’ll have to look at the Modified Date in Details View to know when the snapshot was run. Or hope that the report developer included a textbox to show the execution time in the report. (Hint: this is a good time to add this to your list of report development best practices, whether a report gets set up as a report snapshot or not!)

A snapshot from the past

In case you don’t remember how a snapshot appeared in Report Manager back in the old days (of SQL Server 2008 and earlier), here’s an image I snagged from my Reporting Services 2008 Step by Step manuscript:

A snapshot in the present

A report server running in SharePoint integrated mode had no such label. There you had to rely on the Report Modified date-time stamp to know the snapshot execution time. So I guess all platforms are now consistent.

Here’s a screenshot of Report Manager in the 2008 R2 version. One of these is a snapshot and the rest execute on demand. Can you tell which is the snapshot?

Consider descriptions as an alternative

So my report snapshot demonstration has one less step, and I’ll need to edit the Denali version of the Step by Step book. Things are simpler this way, but I sure wish we had an easier way to identify the execution methods of the reports. Consider using the description field to alert users that the report is a snapshot. It might save you a few questions about why the data isn’t up-to-date if the users know that something changed in the source of the report. Notice that the full description doesn’t display in Tile View, so keep it short and sweet or instruct users to open Details View to see the entire description.

Border integrity notwithstanding, the good news is that even though Microsoft doesn’t give you international maps in the map gallery, you can do it yourself. The files that the Reporting Services installation provides are simply reports created using TIGER/Line Shapefiles available free from the United States Census Bureau and stored in the Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\MapGallery folder. (Look in the Program Files (x36) folder if you’re developing on a 64-bit computer.) You can add your own reports to this same folder to update the map gallery.

You can’t add just any report to the Map Gallery for this technique to work. The report must contain a map with embedded spatial data. You can create such a report by creating a map using any of the three options for spatial data – map gallery, ESRI Shapefile, or a SQL Server spatial query. Then, on the “Choose spatial data and map view options” page of the Map Wizard, you must select the “Embed map data in the report” option as shown below.

Using the map that I created for my post earlier this year about the map control, I eliminated the point layer and then saved the RDL file to the map gallery folder. Then whenever I want to create a new map for France, I can select it in the Map Wizard as shown below.

If you plan to use this option for making additional maps available to report developers, be aware that you must do this on every computer using Business Intelligence Development Studio to create reports. If you have users creating reports with Report Builder 3.0, you also need to store the map RDL in the following location: C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\ReportServer\ReportBuilder\RptBuilder_3\MapGallery where MSRS10_50.MSSQLSERVER is the name of the Reporting Services instance.

The entrance of Microsoft Office SharePoint Server 2007 into the BI stack complicated matters and I started using Virtual Server to establish a “suitable” environment. As part of the team that delivered a lot of education as part of the Yukon pre-launch activities (that would be SQL Server 2005 for the uninitiated), I was working with four – yes, four – virtual servers. That was a pretty brutal workload for a 2GB laptop, which worked if I was very, very careful. It could also be a finicky and unreliable configuration as I learned to my dismay at one TechEd session several years ago when I had to reboot a very carefully cached set of servers just minutes before my session started. Although it worked, it came back to life very, very slowly much to the displeasure of the audience. They couldn’t possibly have been less pleased than me.

At that moment, I resolved to get the beefiest environment I could afford and consolidate to a single virtual server. Enter the 4GB 64-bit laptop to preserve my sanity and my livelihood. Likewise, for SQL Server 2008, I managed to keep everything within a single virtual server and I could function reasonably well with this approach.

Now we have SQL Server 2008 R2 plus Office SharePoint Server 2010. That means a 64-bit operating system. Period. That means no more Virtual Server. That means I must use Hyper-V or another alternative. I’ve heard alternatives exist, but my few dabbles in this area did not yield positive results. It might have been just me having issues rather than any failure of those technologies to adequately support the requirements.

My first run at working with the new BI stack configuration was to set up a 64-bit 4GB laptop with a dual-boot to run Windows Server 2008 R2 with Hyper-V. However, I was generally not happy with running Windows Server 2008 R2 on my laptop. For one, I couldn’t put it into sleep mode, which is helpful if I want to prepare for a presentation beforehand and then walk to the podium without the need to hold my laptop in its open state along the way (my strategy at the TechEd session long, long ago). Secondly, it was finicky with projectors. I had issues from time to time and while I always eventually got it to work, I didn’t appreciate those nerve-wracking moments wondering whether this would be the time that it wouldn’t work.

Somewhere along the way, I learned that it was possible to load SharePoint 2010 in a Windows 7 which piqued my interest. I had just acquired a new laptop running Windows 7 64-bit, and thought surely running the BI stack natively on my laptop must be better than running Hyper-V. (I have not tried booting to Hyper-V VHD yet, but that’s on my list of things to try so the jury of one is still out on this approach.) Recently, I had to build up a server with the RTM versions of SQL Server 2008 R2 and Sharepoint Server 2010 and decided to follow suit on my Windows 7 Ultimate 64-bit laptop. The process is slightly different, but I’m happy to report that it IS possible, although I had some fits and starts along the way.

DISCLAIMER 1: These products are NOT intended to be run in production mode on the Windows 7 operating system. The configuration described in this post is strictly for development or learning purposes and not supported by Microsoft. If you have trouble, you will NOT get help from them. I might be able to help, but I provide no guarantees of my ability or availablity to help.

DISCLAIMER 2: The instructions below apply only to an environment in which the Windows 7 client is joined to a domain. You must log into the client machine using a valid Windows user account for that domain. Thanks to Kevin who pointed out this requirement which I had neglected to mention in my initial post (Updated May 30, 2010).

I won’t provide the step-by-step instructions in this post as there are other resources that provide these details, but I will provide an overview of my approach, point you to the relevant resources, describe some of the problems I encountered, and explain how I addressed those problems to achieve my desired goal.

Because my goal was not simply to set up SharePoint Server 2010 on my laptop, but specifically PowerPivot for SharePoint, I started out by referring to the installation instructions at the PowerPiovt-Info site, but mainly to confirm that I was performing steps in the proper sequence. I didn’t perform the steps in Part 1 because those steps are applicable only to a server operating system which I am not running on my laptop. Then, the instructions in Part 2, won’t work exactly as written for the same reason. Instead, I followed the instructions on MSDN, Setting Up the Development Environment for SharePoint 2010 on Windows Vista, Windows 7, and Windows Server 2008. In general, I found the following differences in installation steps from the steps at PowerPivot-Info:

• You must copy the SharePoint installation media to the local drive so that you can edit the config.xml to allow installation on a Windows client.
• You also have to manually install the prerequisites. The instructions provides links to each item that you must manually install and provides a command-line instruction to execute which enables required Windows features.

I will digress for a moment to save you some grief in the sequence of steps to perform. I discovered later that a missing step in the MSDN instructions is to install the November CTP Reporting Services add-in for SharePoint. When I went to test my SharePoint site (I believe I tested after I had a successful PowerPivot installation), I ran into the following error:

Could not load file or assembly ‘RSSharePointSoapProxy, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91′ or one of its dependencies. The system cannot find the file specified.

I was rather surprised that Reporting Services was required. Then I found an article by Alan le Marquand, Working Together: SQL Server 2008 R2 Reporting Services Integration in SharePoint 2010,that instructed readers to install the November add-in. My first reaction was, “Really?!?” But I confirmed it in another TechNet article on hardware and software requirements for SharePoint Server 2010. It doesn’t refer explicitly to the November CTP but following the link took me there. (Interestingly, I retested today and there’s no longer any reference to the November CTP. Here’s the link to download the latest and greatest Reporting Services Add-in for SharePoint Technologies 2010.) You don’t need to download the add-in anymore if you’re doing a regular server-based installation of SharePoint because it installs as part of the prerequisites automatically.

When it was time to start the installation of SharePoint, I deviated from the MSDN instructions and from the PowerPivot-Info instructions:

• On the Choose the installation you want page of the installation wizard, I chose Server Farm.
• On the Server Type page, I chose Complete.
• At the end of the installation, I did not run the configuration wizard.

Returning to the PowerPivot-Info instructions, I tried to follow the instructions in Part 3 which describe installing SQL Server 2008 R2 with the PowerPivot option. These instructions tell you to choose the New Server option on the Setup Role page where you add PowerPivot for SharePoint. However, I ran into problems with this approach and got installation errors at the end.

It wasn’t until much later as I was investigating an error that I encountered Dave Wickert’s post that installing PowerPivot for SharePoint on Windows 7 is unsupported. Uh oh. But he did want to hear about it if anyone succeeded, so I decided to take the plunge. Perseverance paid off, and I can happily inform Dave that it does work so far. I haven’t tested absolutely everything with PowerPivot for SharePoint but have successfully deployed a workbook and viewed the PowerPivot Management Dashboard. I have not yet tested the data refresh feature, but I have installed. Continue reading to see how I accomplished my objective.

I unintalled SQL Server 2008 R2 and started again. I had different problems which I don’t recollect now. However, I uninstalled again and approached installation from a different angle and my next attempt succeeded. The downside of this approach is that you must do all of the things yourself that are done automatically when you install PowerPivot as a new server. Here are the steps that I followed:

• Install SQL Server 2008 R2 to get a database engine instance installed.
• Run the SharePoint configuration wizard to set up the SharePoint databases.
• In Central Administration, create a Web application using classic mode authentication as per a TechNet article on PowerPivot Authentication and Authorization.
• Then I followed the steps I found at How to: Install PowerPivot for SharePoint on an Existing SharePoint Server. Especially important to note – you must launch setup by using Run as administrator. I did not have to manually deploy the PowerPivot solution as the instructions specify, but it’s good to know about this step because it tells you where to look in Central Administration to confirm a successful deployment.

I did spot some incorrect steps in the instructions (at the time of this writing) in How To: Configure Stored Credentials for PowerPivot Data Refresh. Specifically, in the section entitled Step 1: Create a target application and set the credentials, both steps 10 and 12 are incorrect. They tell you to provide an actual Windows user name and password on the page where you are simply defining the prompts for your application in the Secure Store Service. To add the Windows user name and password that you want to associate with the application – after you have successfully created the target application – you select the target application and then click Set credentials in the ribbon.

Lastly, I followed the instructions at How to: Install Office Data Connectivity Components on a PowerPivot server. However, I have yet to test this in my current environment.

I did have several stops and starts throughout this process and edited those out to spare you from reading non-essential information. I believe the explanation I have provided here accurately reflect the steps I followed to produce a working configuration. If you follow these steps and get a different result, please let me know so that together we can work through the issue and correct these instructions. I’m sure there are many other folks in the Microsoft BI community that will appreciate the ability to set up the BI stack in a Windows 7 environment for development or learning purposes.

• Map Gallery – a set of Shapefiles for the United States only that ships with Reporting Services
• ESRI Shapefile – a .shp file conforming to the Environmental Systems Research Institute, Inc. (ESRI) shapefile spatial data format
• SQL Server spatial data – a query that includes SQLGeography or SQLGeometry data types

Rob Farley (blog|twitter) points out today in his T-SQL Tuesday post that using the SQL geography field is a preferable alternative to ESRI shapefiles for storing spatial data in SQL Server. So how do you get spatial data? If you don’t already have a GIS application in-house, you can find a variety of sources. Here are a few to get you started:

• US Census Bureau Website, http://www.census.gov/geo/www/tiger/
• Global Administrative Areas Spatial Database, http://biogeo.berkeley.edu/gadm/
• Digital Chart of the World Data Server, http://www.maproom.psu.edu/dcw/

In a recent post by Pinal Dave (blog|twitter), you can find a link to free shapefiles for download and a tutorial for using Shape2SQL, a free tool to convert shapefiles into SQL Server data.

In my post today, I’ll show you how to use combine spatial data that describes boundaries with spatial data in AdventureWorks2008R2 that identifies stores locations to embed a map in a report.

Preparing the spatial data

First, I downloaded Shapefile data for the administrative boundaries in France and unzipped the data to a local folder. Then I used Shape2SQL to upload the data into a SQL Server database called Spatial. I’m not sure of the reason why, but I had to uncheck the option to create a spatial index to upload the data. Otherwise, the upload appeared to run successfully, but no table appeared in my database.

The zip file that I downloaded contained three files, but I didn’t know what was in them until I used Shape2SQL to upload the data into tables. Then I found that FRA_adm0 contains spatial data for the country of France, FRA_adm1 contains spatial data for each region, and FRA_adm2 contains spatial data for each department (a subdivision of region).

Next I prepared my SQL query containing sales data for fictional stores selling Adventure Works products in France. The Person.Address table in the AdventureWorks2008R2 database (which you can download from Codeplex) contains a SpatialLocation column which I joined – along with several other tables – to the Sales.Customer and Sales.Store tables. I’ll be able to superimpose this data on a map to see where these stores are located. I included the SQL script for this query (as well as the spatial data for France) in the downloadable project that I created for this post.

Step 1: Using the Map Wizard to Create a Map of France

You can build a map without using the wizard, but I find it’s rather useful in this case. Whether you use Business Intelligence Development Studio (BIDS) or Report Builder 3.0, the map wizard is the same. I used BIDS so that I could create a project that includes all the files related to this post. To get started, I added an empty report template to the project and named it France Stores. Then I opened the Toolbox window and dragged the Map item to the report body which starts the wizard. Here are the steps to perform to create a map of France:

1. On the Choose a source of spatial data page of the wizard, select SQL Server spatial query, and click Next.
2. On the Choose a dataset with SQL Server spatial data page, select Add a new dataset with SQL Server spatial data.
3. On the Choose a connection to a SQL Server spatial data source page, select New.
4. In the Data Source Properties dialog box, on the General page, add a connecton string like this (changing your server name if necessary):
   Data Source=(local);Initial Catalog=Spatial
5. Click OK and then click Next.
6. On the Design a query page, add a query for the country shape, like this:
   select * from fra_adm1
7. Click Next. The map wizard reads the spatial data and renders it for you on the Choose spatial data and map view options page, as shown below.
   
   You have the option to add a Bing Maps layer which shows surrounding countries. Depending on the type of Bing Maps layer that you choose to add (from Road, Aerial, or Hybrid) and the zoom percentage you select, you can view city names and roads and various boundaries. To keep from cluttering my map, I’m going to omit the Bing Maps layer in this example, but I do recommend that you experiment with this feature. It’s a nice integration feature.
8. Use the + or – button to rexize the map as needed. (I used the + button to increase the size of the map until its edges were just inside the boundaries of the visible map area (which is called the viewport). You can eliminate the color scale and distance scale boxes that appear in the map area later.
9. Select the Embed map data in this report for faster rendering. The spatial data won’t be changing, so there’s no need to leave it in the database. However, it does increase the size of the RDL. Click Next.
10. On the Choose map visualization page, select Basic Map. We’ll add data for visualization later. For now, we have just the outline of France to serve as the foundation layer for our map. Click Next, and then click Finish.
11. Now click the color scale box in the lower left corner of the map, and press the Delete key to remove it. Then repeat to remove the distance scale box in the lower right corner of the map.

Step 2: Add a Map Layer to an Existing Map

The map data region allows you to add multiple layers. Each layer is associated with a different data set. Thus far, we have the spatial data that defines the regional boundaries in the first map layer. Now I’ll add in another layer for the store locations by following these steps:

1. If the Map Layers windows is not visible, click the report body, and then click twice anywhere on the map data region to display it.
2. Click on the New Layer Wizard button in the Map layers window.
   
   And then we start over again with the process by choosing a spatial data source.
3. Select SQL Server spatial query, and click Next.
4. Select Add a new dataset with SQL Server spatial data, and click Next.
5. Click New, add a connection string to the AdventureWorks2008R2 database, and click Next.
6. Add a query with spatial data (like the one I included in the downloadable project), and click Next.
7. The location data now appears as another layer on top of the regional map created earlier. Use the + button to resize the map again to fill as much of the viewport as possible without cutting off edges of the map. You might need to drag the map within the viewport to center it properly.
8. Select Embed map data in this report, and click Next.
9. On the Choose map visualization page, select Basic Marker Map, and click Next.
10. On the Choose color theme and data visualization page, in the Marker drop-down list, change the marker to diamond. There’s no particular reason for a diamond; I think it stands out a little better than a circle on this map. Clear the Single color map checkbox as another way to distinguish the markers from the map.
    You can of course create an analytical map instead, which would change the size and/or color of the markers according to criteria that you specify, such as sales volume of each store, but I’ll save that exploration for another post on another day.
11. Click Finish and then click Preview to see the rendered report. Et voilà…c’est fini.
    
    Yes, it’s a very simple map at this point, but there are many other things you can do to enhance the map. I’ll create a series of posts to explore the possibilities.

• IntroSQLServer2008R2Samples project
• Sales Analysis workbook

Here’s a recap of the business intelligence chapters and the samples I used to generate the screen shots by chapter:

Chapter 6: Scalable Data Warehousing covers a new edition of SQL Server, Parallel Data Warehouse. Understandably, Microsoft did not ship me the software and hardware to set up my own Parallel Data Warehouse environment for testing purposes and consequently you won’t see any screenshots in this chapter. I received a lot of information and a lot of help from the product team during the development of this chapter to ensure its technical accuracy.

Chapter 7: Master Data Services is a new component in SQL Server. After you install Master Data Services (MDS), which is a separate installation from SQL Server although it’s found on the same media, you can install sample models to explore (which is what I did to create screenshots for the book). To do this, you deploying packages found at \Program Files\Microsoft SQL Server\Master Data Services\Samples\Packages. You will first need to use the Configuration Manager (in the Microsoft SQL Server 2008 R2\Master Data Services program group) to create a database and a Web application for MDS. Then when you launch the application, you’ll see a Getting Started page which has a Deploy Sample Data link that you can use to deploy any of the sample packages.

Chapter 8: Complex Event Processing is an introduction to another new component, StreamInsight. This topic was way too large to cover in-depth in a single chapter, so I focused on information such as architecture, development models, and an overview of the key sections of code you’ll need to develop for your own applications. StreamInsight is an engine that operates on data in-flight and as such has no user interface that I could include in the book as screenshots. The November CTP version of SQL Server 2008 R2 included code samples as part of the installation, but these are not the official samples that will eventually be available in Codeplex. At the time of this writing, the samples are not yet published.

Chapter 9: Reporting Services Enhancements provides an overview of all the changes to Reporting Services in SQL Server 2008 R2, and there are many! In previous posts, I shared more details than you’ll find in the book about new functions (Lookup, MultiLookup, and LookupSet), properties for page numbering, and the new global variable RenderFormat. I will confess that I didn’t use actual data in the book for my discussion on the Lookup functions, but I did create real reports for the blog posts and will upload those separately. For the other screenshots and examples in the book, I have created the IntroSQLServer2008R2Samples project for you to download. To preview these reports in Business Intelligence Development Studio, you must have the AdventureWorksDW2008R2 database installed, and you must download and install SQL Server 2008 R2. For the map report, you must execute the PopulationData.sql script that I included in the samples file to add a table to the AdventureWorksDW2008R2 database. The IntroSQLServer2008R2Samples project includes the following files:

• 01_AggregateOfAggregates.rdl to illustrate the use of embedded aggregate functions
• 02_RenderFormatAndPaging.rdl to illustrate the use of page break properties (Disabled, ResetPageNumber), the PageName property, and the RenderFormat global variable
• 03_DataSynchronization.rdl to illustrate the use of the DomainScope property
• 04_TextboxOrientation.rdl to illustrate the use of the WritingMode property
• 05_DataBar.rdl
• 06_Sparklines.rdl
• 07_Indicators.rdl
• 08_Map.rdl to illustrate a simple analytical map that uses color to show population counts by state
• PopulationData.sql to provide the data necessary for the map report

Chapter 10: Self-Service Analysis with PowerPivot introduces two new components to the Microsoft BI stack, PowerPivot for Excel  and PowerPivot for SharePoint, which you can learn more about at the PowerPivot site. To produce the screenshots for this chapter, I created the Sales Analysis workbook which you can download (although you must have Excel 2010 and the PowerPivot for Excel add-in installed to explore it fully). It’s a rather simple workbook because space in the book did not permit a complete exploration of all the wonderful things you can do with PowerPivot. I used a tutorial that was available with the CTP version as a basis for the report so it might look familiar if you’ve already started learning about PowerPivot.

In future posts, I’ll continue exploring the new features in greater detail. If there’s any special requests, please let me know!

One of the problems that I currently have with earlier versions of Reporting Services is the inability to control page numbering when I use subreports. I have a situation where I have many individual reports that I want to combine into a single PDF document for distribution. Page numbering is available only in the page header or page footer of a report, so I can’t define the page numbering strategy in the report that I define as a subreport. And even if I could, prior to SQL Server 2008 R2, there was no simple way to renumber pages dynamically within the report. That is, the page numbering applies to the entire report. I cannot number the pages in a distinct section of the report separately from other sections.

With the new version of Reporting Services, I can now solve this problem. Not only can I have separate page numbering by “section”, but I can also assign names to each “section”. For this example, I’ve taken a very simple approach to prove out what’s possible. That means it’s  not pretty or elegant, or meant to illustrate best practices, but it’s functional and to the point. Let’s get started.

The master report contains a Tablix data region which has a PageName property that I can use for naming the first section of my report, as shown in Figure 1. You can use static text, as I have done, or you can use an expression. The PageName property is a property of a data region or a group. I haven’t tested it extensively, but it appears to remain constant from page to page until the report execution renders another data region or group where the PageName property is set to a new value.

Figure 1

In the report that I’ll use as a subreport, I set the PageName property to Sales Summary, on the outermost tablix. You’ll see later that this property “pulls through” to the rendered report. I can also set page breaks (see Figure 2) on the groups in that report which appear in the rendered report, which I have on the group (which breaks on calendar year) of the outermost tablix. The only thing that I cannot define in this report is page numbering because pagination properties are ignored when a report is used as a subreport. Note that the PageName is left blank here. It will continue to use Sales Summary which is defined on the Tablix2 object.

Figure 2

Now the problem that I have with subreports is that there is no way for me to tell it to 1) insert a page break before rendering the subreport, and 2) reset the page numbering. However, I can use a rectangle to handle the pagination for me. So I add a rectangle to MasterReport, insert a subreport inside the rectangle, and configure the subreport to point to the ResellerSales report. Next, I configure the pagination properties on the rectangle, as shown in Figure 3. I force a page break with BreakLocation = Start, and set ResetPageNumber to True.

Figure 3

The page number reset applies only to the current page counter. You display the value of the current page counter in the page header or footer by using the Globals!PageNumber, which has always been a part of Reporting Services. However, in SSRS 2008 R2, you can now reset the current page counter to zero anytime you want to begin a new page numbering sequence in your report. Meanwhile, you can display the running count of ALL pages in your report by using the new globals, Globals!OverallPageNumber and Globals!OverallTotalPages. To illustrate the two page counters, I have two textboxes in the page footer of my report (which is the only place you can use the globals related to pagination).

The first expression applies the current section of my report which is affected by the page number reset and displays the value of the PageName property:

=Globals!PageName + " "  + CStr(Globals!PageNumber) + " of " + CStr(Globals!TotalPages)

The second expression displays the overall page count, which is unaffected by the page number reset:

=CStr(Globals!OverallPageNumber) + " of " + CStr(Globals!OverallTotalPages) + " Overall"

Now when I preview the report, I see the footer shown in Figure 4 on the first page of the report. Here you can see the first “section” of the report is a total of 5 pages while the overall report is 9 pages.

Figure 4

And then paging forward to the first page of the subreport, I find the footer shown in Figure 5. The PageName property of the tablix in the subreport now replaces the prior page name. (Remember that you can use an expression instead of static text.)

Figure 5

If you want to take a closer look, you can download my project and try it out yourself. To execute the report, you must have the AdventureWorksDW2008R2 database installed, and you must download and install SQL Server 2008 R2.

First, a quick review. The Lookup function evaluates one value per row in the source to find one value for that row in the destination and the MultiLookup function evaluates one set of values per row, finds each matching value in the destination, and returns the matches in a set. LookupSet evaluates each row in the source and looks for all matches in the destination, returning the resulting matches as a set.

To illustrate how to use LookupSet, I want to produce a list of the sales by state and include a count of customers so that I can compare the average sales per customer by state. In Dataset1, I have a list of the states’ two-letter codes and total sales. In Dataset2, I have a list of customer IDs and the state associated with the customer. You can see a sample of data in each of these datasets below in Figure 1.

Figure 1

If you look at the report layout and a portion of the report shown in Figure 2, you can infer that I have a combination of lookups in play. The report is a simple table that includes StateProvinceCode in the first column. In the State column, I  use the Lookup function in an expression to get the state name from a third dataset. In the Customer Count column, I have an expression that includes the LookupSet function to retrieve the set of customers for the state on the current row and then I use a Count function on that set. Of course, if I wanted a list of those customers, I could use the Join function to convert the array that returns from the LookupSet function into a string. Continuing on with this example, though, I have SalesAmount from Dataset1, and then another expression for “Avg Sale Per Customer” that divides SalesAmount by Customer Count.

Figure 2

The expression in the Customer Count column uses the LookupSet function and looks like this:

=LookupSet(Fields!StateProvinceCode.Value,Fields!StateProvinceCode.Value,
Fields!CustomerID.Value,"Dataset2").Length

LookupSet takes four arguments, much like the Lookup function except that Lookup returns a single value per row whereas LookupSet returns an array:

1. The first argument, Fields!StateProvinceCode.Value,  is a field in the dataset that is bound to the data region (Dataset1 in this example).
2. The second argument is the StateProvinceCode field in Dataset2 that you use as the lookup field. The LookupSet function matches each value in the Dataset1 field with a value in the Dataset2 field. The values to match must have the same data type.
3. The third argument, Fields!CustomerID.Value, is the field in Dataset2 that you want to return as the function result. The difference here between the Lookup and LookupSet functions is that the Lookup function returns the first value it finds, but LookupSet returns an array of all matching values that it finds.
4. The fourth and final argument is the name of the second dataset which must be enclosed in quotes and is case-sensitive.

LookupSet returns an array, so you can’t use the results directly in the table but must use some other function to operate on the array to get a single value.

I like pictures to help me understand how things work, so I created Figure 3 below as another way to visualize what the LookupSet function does.

And that concludes this series on the new Lookup functions in SQL Server 2008 R2 Reporting Services. I hope you find these explanations useful. I admit that I haven’t had a compelling need for them, but that’s because I do the necessary integration in the back-end first – either by querying a data mart/warehouse or by joining the data in the dataset. However, I can imagine scenarios where those two options aren’t available in which case having the Lookup functions as an alternative is helpful. What do you think?

• Lookup
• MultiLookup
• LookupSet

Today, we’ll take a closer look at the MultiLookup function. Remember from the discussion in Part I that the Lookup function evaluates one value per row in the source to find one value for that row in the destination. By contrast, the MultiLookup function evaluates one set of values per row, finds each matching value in the destination, and returns the matches in a set. To better understand how to use it, let’s look at an example of how to use this function. In this example, I want to produce a list of the sales of each salesperson and include a list of the states in each person’s sales territory. In my first dataset, I have a comma-delimited list of two-letter codes for the states in each person’s sales territory. In the second dataset, I have a list of states with their corresponding two-letter codes. The two datasets are shown below in Figure 1.

Next, I create a simple table that contains the SalesPerson and the SalesAmount field from Dataset1. I also have an expression in the first column. The layout and a portion of the report are shown in Figure 2.

The expression uses the MultiLookup function and looks like this:

=Join(MultiLookup(Split(Fields!StateList.Value, ","), Fields!StateProvinceCode.Value,
Fields!Name.Value,"Dataset2"), chr(10))

The MultiLookup function takes four arguments:

1. The first argument, Split(Fields!StateList.Value, “,”), is an expression based on the StateList field found in the dataset that is bound to the data region, which is Dataset1 in this example. The StateList field contains a comma-delimited list which is transformed into an array by using the Split function.
2. The second argument is the StateProvinceCode field in Dataset2 that you use as the lookup field. In other words, you are matching each item in the array made from the StateList field in Dataset1 with a StateProvinceCode in Dataset2. The values to match must have the same data type.
3. The third argument, Fields!Name.Value, is the field (or expression) in the second dataset that you want to return as the function result. The difference here between the Lookup and MultiLookp functions is that the Lookup function returns a single value but MultiLookup returns an array.
4. The fourth and final argument is the name of the second dataset which must be enclosed in quotes and is case-sensitive.

Because this function returns an array of values, the Join function is used to convert the array back to a string of values. For presentation purposes, rather than use a comma separator, I used chr(10) to present each state on a separate line.

Figure 3 shows another way to visualize what the MultiLookup function does.

In my next post, I’ll explain the last of the lookup functions, LookupSet.

There are three lookup functions available:

• Lookup
• MultiLookup
• LookupSet

My focus today is on the Lookup function. This function is in effect a join between two datasets where there is a one-to-one relationship between the source and destination. Let’s say that I want to produce a report of sales by state, but the dataset that I have for sales provides the two-letter code for state. Let’s say also that I find another dataset that provides a list of states and the two-letter code for each state. Now I have two datasets available, shown below in Figure 1, for my report.

Figure 1

Next, I create a simple table, add the SalesAmount field from Dataset1 to the table, and add an expression in the first column. The layout and a portion of the report are shown in Figure 2.

Figure 2

The expression uses the Lookup function and looks like this:

=Lookup(Fields!StateProvinceCode.Value,Fields!StateProvinceCode.Value,Fields!Name.Value,"Dataset2")

The Lookup function takes four arguments:

1. The first argument, Fields!StateProvinceCode, is a field (or expression based on a field) from the dataset that is bound to the data region, which is Dataset1 in this example.
2. The second argument is a field (or expression) from the dataset that you want to use for the lookup. In this example, the second dataset also contains a field called StateProvinceCode, but it’s okay if the field names are different in each dataset. They should, of course, contain data that matches up and they must have the same data type. You can think of the first and second arguments as analogous to two columns that you want to use to define a join between two tables.
3. The third argument, which is Fields!Name.Value in this example, is the field (or expression) in the second dataset that you want to return as the function result.
4. The fourth and final argument is the name of the second dataset which must be enclosed in quotes and is case-sensitive.

If you need to match two fields in the first dataset to two fields in the second dataset, that’s okay. You simply create an expression to concatenate the pair of fields and use that expression in the argument in the Lookup function. Your expression cannot include report or group variables, however, nor can it include another lookup function.

Figure 3 shows another way to visualize what the Lookup function does.

Figure 3

Note that Reporting Services processes the Lookup function on the scope of the expression, which is in this case is the detail rows of the table which correspond to the rows of Dataset1. Using the Lookup function, Reporting Services uses a single value for the current row in the first dataset to find the first match in the second dataset and returns a single value. By contrast, the other two lookup functions, MultiLookup and LookupSet work with arrays. Next week, I’ll continue with Part II and Part III to explain how to use these functions.

In SQL Server 2008 R2, a simple, but oh so important, feature is now available. The data source page in Report Manager now has a Test Connection button, shown in the figure below, that lets you know right away whether the data source is working or not.  This feature makes its debut appearance in the RC0 version of Reporting Services.