Is it possible to transform connection strings when deploying reports? (SSDT BIDS For VS 2012/SSRS)

Question

Firstly, this is not my area of expertise, so I apologise in advance for my lack of intuition and naivety when it comes to this sphere. I am merely trying to help out a colleague. Also, please let me know if this fits better on the DBAdmin StackExchange site. Apologies and disclaimers notwithstanding...

I have been watching a non-programming colleague of mine struggle endlessly with hard coded connection strings in his datasets and projects in 2008 Business Intelligence Development Studio (BIDS) during creation of Reports. It has reached the point whereby he maintains three versions of absolutely everything (one for each of our environments, with specific connections hard-coded into each). In the last few days, he has taken the plunge and upgraded to SSDT BIDS for VS 2012.

Edit to add:

---

He has a single report server instance, where he has three versions of everything for each of the environments that connect to it, he doesn't have a report server for each of the environments. So, to publish everything correctly, he has to maintain three identical (bar the connection string) projects and datasets and modify all three when a change is needed. What he'd like to be able to do, is not to have to maintain three report projects, but merely change a setting and redeploy his report for that environment. I think we're swimming upstream on this issue and are willing to consider redesigning the architecture of our reporting.

---

Coming from the web sphere, my initial blind thought was: if you're using Visual Studio, why not store the connections strings in config files and transform them on publish using SlowCheetah to transform any type of config file? The answer that came back from the IDE was: not so fast, seeing as connection strings are stored within the user interface, inside Properties windows of the objects themselves.

Soldiering on through endless web searches, I discovered another technique called Expression-based Connection Strings (bottom of the page), but this seems a little insecure to my untrained eye, but is this what I have been looking for?

I appreciate that this is not necessarily the archetypal SO question, but if anyone has any knowledge to impart on how to do transformed deployments in BIDS so that we can reduce our duplication threefold, I would be eternally grateful.

Answer 1

Have you considered using Shared Data Sources for your reports if you aren't using these already?

That way you define the Data Source(s) once for each environment, then when deploying the reports to different environments as long as the Data Sources are always named the same and in the same relative location to the report you shouldn't need to worry about updating connection strings each time.

There are a few challenges that can be solved in different ways (e.g. uploading a new report through Report Manager invalidates the existing Data Source reference), but this is a pretty standard and scalable approach.

Added after comment:

Thanks for the update.

Given you have one instance with multiple deployments, Expression-based connection strings aren't a bad option.

The only issue is that you need some way of choosing the Data Source, such as a parameter. If you're happy to have user's choose this (or through any other mechanism you can think of) this would be a good option.

In terms of security, this would be no different than any other static Data Source; you choose whatever credentials you like, e.g. Windows Authentication, stored credentials... These are treated exactly the same so there's no extra consideration here.

One other option you might consider is deploying your reports through the rs Utility. You could parameterise a deployment script to deploy all the reports to one of a number of folders on the server, and point the reports to one of a number of Data Sources on the server.

Once you have the script working you could even wrap this in one batch file for each of your environments and deploy and configure your reports just by running the batch file.

Summary

If possible, I'd still go for separate instances and control deployments through BIDS and build configurations (Develop, Release, etc) which have different instance targets. If you have some SQL Server Development licences this could be an option.

Failing that, either of the other options should work, too - expression-based connection strings move the complexity into the report and/or the calling application or keeping it out of the reports and putting some effort now into some deployment scripts that should make deploying reports through fairly robust batch files.

Answer 2

1. Here I have Create a data source named "prod_data_source" in your QA and then in your The Connection string in QA as below

Data Source=xxxx;Initial Catalog=xxx

2. PROD environment. The data source names should be the same (including upper/lower case).
3. In PROD the data source will point to your PROD DB and use PROD credentials
4. In QA the data source will point to your QA DB and use QA credentials
5. When you deploy reports, do not deploy data sources. Only deploy reports. Hopefully that is a possibility.
6. When you deploy only reports, the report will look for the data source ("prod_data_source") in the current environment and that environment will have the same data source name but will connect to the correct DB behind the scenes. )
7. Create the same data source (configuration of the connection) in each environment. You will name it anything. In my example, I named it "prod_data_source". Each environment will have the same data source but they will be pointing to different databases.