I'm trying to figure out how a shared data source works, specifically thebenefit of using a shareddata source.I'm working with the following set up which I've inherited and I'm wondering if I should keep it this way or change to some other set up. Here is what I have and what I'm trying to do. When I log on to management studio into reporting services, here are the folders I see under "Home". (What you are about to see is what I've inherited, but I don't necessarily need to stay with this. So let me know if this make sense.) "Data Source", "Folder1", "Folder2", ... Folder_N". "Data Source" folder contains the various data sources that are to be references by the various reports. The numbered folders containvarious groups of reports. The folders arenot actually named this way. I just named them with numbers here as examples. When I go into any one of the numbered folders, I have the various rdl files. When I expand one of these rdls, I see there is another folder called "Data Sources", which has a data source that references one of the data sources contained in the folder "Data Source" directly under "Home". Now, I want to add another report to one of these numbered folders. To do this, I designed a report using a data set that uses a shared data source (.rds). I namethis shared data source the samething as the one found on the server, with the expectation that when I import this .rdl into the server, it will know to use the particular data source under the "Data Source" directory. However, when I import this new .rdl on to the server, its Data Source says, "The shared data source reference is no longer valid." To make it see the intended data source, I need to click on the ellipse and navigate to the data source at the higher level. I hope you were able to follow this description. And if so, am I correct in expecting the imported report to know which shared data source reference to use? Or do I need to set this for every report that I bring in?

In SSRS, a catalog item is referenced by its path in the report catalog, much like in the Windows file system. If you inspect the report RDL in BIDS, you'll see that there is no path to the data source b/c Visual Studio doesn't support folders and the report would expect the data source to be in the same folder it's deployed to. However, you can go to the project properties (assuming BIDS deployment) and set the TargetDataSourceFolder and OverwriteDataSources to True. On deploy, BIDS deployment would change the deployed report to reference the data source from the TargetDataSourceFolder folder you specify.

Teo Lachev wrote: In SSRS, a catalog item is referenced by its path in the report catalog, much like in the Windows file system. If you inspect the report RDL in BIDS, you'll see that there is no path to the data source b/c Visual Studio doesn't support folders and the report would expect the data source to be in the same folder it's deployed to. However, you can go to the project properties (assuming BIDS deployment) and set the TargetDataSourceFolder and OverwriteDataSources to True. On deploy, BIDS deployment would change the deployed report to reference the data source from the TargetDataSourceFolder folder you specify. Ok, I've shy-ed away from using the BIDs deployment because I wasn't sure how it worked but I tried it by setting the options you specified, and I now see that it automatically creates the data source reference at the "Data Source" folder on the reports server. Furthermore,I now see the value in the shared data source, and let me know if I'm correct with the following understanding/observation. When I deploy a project to the server, which includes the shared data source, I can set the connection string to the appropriate value for that environment, ie, production vs development vs test, etc. Once that is set on the various servers, the next time I deploy, I set OverwriteDataSources to False, which allows me to work in BIDs under a certain environment but not change the data source connection strings on the already deployed projects... correct?

When I deploy a project to the server, which includes the shared data source, I can set the connection string to the appropriate value for that environment, ie, production vs development vs test, etc. Yes, the best way to handle this is via BIDS project configurations although SSRS projects currently don't maintain configuration-specific connection strings (SSAS and SSIS projects do). ...next time I deploy, I set OverwriteDataSources to False, which allows me to work in BIDs under a certain environment but not change the data source connection strings on the already deployed projects... correct? Correct, when OverwriteDataSources is False, the server-side data sources will be unaffected.

There is an application (SSRS Data Source Manager) that can fix missing data sources, and change current data sources for RDL reports and models. It can be used to change a single report / model or allow bulk changes for many reports and models. There is also a health check feature, to detect and correct reports and models that have missing data sources. Multiple data sources for reports and models are also supported. http://www.lecomputing.com/ssrsdatasourcemanager.html Other uses can be- changing a selection of reports to another data source, eg moving from UAT/Development to production, or server loading issues.

What if I can't set up a shared data source at all? I've been getting a message inside VS2005 for Report Wizard "Exception has been thrown by the target of an invocation"SSIS Developer