Click here to Skip to main content
Click here to Skip to main content

Switching Data Sets When Working With Microsoft Reporting Services With SQL

, 14 Sep 2007
Rate this:
Please Sign up or sign in to vote.
Switching Data Sets when working with Microsoft Reporting Services
Screenshot - DataSourcePic.jpg


This article describes how to switch data sources (datasets) when working with a report using Microsoft Reporting Services with SQL Server Business Intelligence Development Studio. This is important when your report may utilize different data sources, for example, one for test and one for production. This solution is based on using the SQL Server Business Intelligence Development Studio to easily make the changes to the data source as opposed to manually editing the report definition language XML source code, which opens up the chance for errors if you don't know what to edit.


This article assumes a working knowledge of using Microsoft Reporting Services with SQL Server Business Intelligence Development Studio.

Using the GUI

You'll first need two shared data sources already set up under "Shared Data Sources" in Solution Explorer. Here I have two listed:

Screenshot - DataSourcePic.jpg

Next, go into an existing report and click on the data tab as shown below. You'll notice I am using a Test data set named "EduLendingTest":

Screenshot - DataTab.jpg

Next, click on the ellipsis button Screenshot - EllipsisButton.jpgnext to the DataSet dropdown menu. The tooltip "Edit Selected DataSet" will appear as shown:

Screenshot - EditDataSetButton.jpg

The DataSet window pop-up will appear. In this window, select the "Data Source" dropdown menu, and select the data source you wish to switch to. In this instance, I am switching to "EduLendingProd (shared)" as shown:

Screenshot - SelectProdDataSet.jpg

Next, change the name of the data set. In this example, I used the same name as the data source I created highlighted here, then clicked OK:

Screenshot - ChangeDataSetNameToProd.jpg

Next, click on the Layout tab:

Screenshot - LayoutTab.jpg

Click on the report table, then right-click the report table and select "Properties":

Screenshot - SelectReportProperties.jpg

In the Table Properties window, select the new data set name from the "Dataset name:" dropdown list as shown here and then click OK:

Screenshot - TablePropertiesWindow.jpg

Save your report and you should be able to use your new data set with the underlying data source.

Points of Interest

This approach was much easier than trying to edit the underlying XML rdl code, which got me in trouble. Hopefully this important, but not well known function will be made easier to use in future releases and will be better documented.


Submitted 09/11/2007


This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here


About the Author

Web Developer
United States United States
Harry is a .NET Developer for a major financial institution building web and stand alone applications and class libraries. He also has experience teaching courses on ASP.NET and Microsoft databases. He holds a graduate degree in Information Science.

Comments and Discussions

GeneralREgenerating Field List Pinmembershumakercs8-Apr-11 12:38 
I know this is only semi relevant to the topic, but whenever the underlying source of the dataset changes, how do you regenerate the field list in the dataset?
I inherited a project and followed a similar process, but the field list remained the same, however the sotpred procedure I used as the source of the dataset query had new fields and some with different names. Rather than manually going through and changing 30 something fields, I instead used the report wizard to create a new report from that stored procedure. I then opened the RDL for both the old and new reports, and copied the field lists from the new report to the old. I did it this way because I wanted to maintain all of the same parameters and expressions of the old report and didn't want to retype all of that. This brought the old report to the point where the field lists were correct, but required some tedious poking through the RDL.
It was definitely alot faster than going through one field at a time in the IDE and copying/pasting or retyping, since I could in some places copy paste big chunks of XML to update all of the columns or the entire fields list.
If you have ideas for a simpler procedure, would be glad to hear them.
GeneralUsing report parameters to build report's connection string would be easier... [modified] PinmemberNino Mrdjen20-May-08 3:24 
GeneralRe: Using report parameters to build report's connection string would be easier... Pinmembercaradens17-Oct-08 15:22 
GeneralRe: Using report parameters to build report's connection string would be easier... PinmemberPonyRydr13-May-11 3:44 
GeneralI can't disagree more! PinmemberKABay20-Sep-07 11:57 
GeneralRe: I can't disagree more! [modified] Pinmemberharryteck24-Sep-07 5:35 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web02 | 2.8.1411023.1 | Last Updated 14 Sep 2007
Article Copyright 2007 by harryteck
Everything else Copyright © CodeProject, 1999-2014
Layout: fixed | fluid