Categories: SSASSSIS

Change SSAS Tabular Data Source using TOM

We’ve all been there. You made some adjustments to your Tabular model and you deploy it to the production server using Visual Studio. Whoops, you forgot to change the server name in the data sources, so now your Tabular model in production is trying to read from the test database. Either it crashes – depending on your impersonation settings – or it doesn’t and it can take a while before someone notices the data in production is a little off.

There are many ways to avoid this scenario. The first one is to not deploy from Visual Studio at all, but rather use a script or the wizard. But you know those rogue BI developers, there will always be one who just right-clicks the Tabular project in Visual Studio and chooses “Deploy”. You could also use configurations in Visual Studio, which were introduced in Tabular 2016. You can find more info in this article. But of course you can still forget to pick the correct configuration before you deploy.

So I created a little script that can be executed in a SSIS script task. You execute it right before you start processing your models in your daily/nightly/hourly/weekly/… batch run. It will loop over the databases in your Tabular server using the Tabular Object Model (TOM), inspect the connections and make sure they are all set to point to the correct server. In the script, I assume SSAS is installed on the same server as the data sources. If this isn’t the case, it’s pretty easy to change. The server name is passed along as a SSIS project variable.

To make the script work, you need to install the correct libraries. More info can be found here. The script itself can be downloaded from Github.


------------------------------------------------
Do you like this blog post? You can thank me by buying me a beer 🙂
Koen Verbeeck

Koen Verbeeck is a Microsoft Business Intelligence consultant at AE, helping clients to get insight in their data. Koen has a comprehensive knowledge of the SQL Server BI stack, with a particular love for Integration Services. He's also a speaker at various conferences.

View Comments

  • You could also disable the deployment rights of (rogue) BI developers and set up a CI/CD build orchestrator (like VSTS) with a build step that runs your script.

Recent Posts

T-SQL Tuesday #199 Invitation: Back to on-prem?

It's time for T-SQL Tuesday again! And we're almost to number 200! T-SQL Tuesday is…

2 hours ago

Error Deploying GraphQL in Fabric: dm_exec_describe_first_result_set

A while ago we suddenly had an error while trying to deploy one Fabric workspace…

23 hours ago

Session Materials for Techorama & DataGrillen 2026

I've uploaded the slides for my Techorama session Microsoft Fabric for Dummies and my DataGrillen…

2 weeks ago

Free Webinar about Columnstore Indexes

I'm doing a small series on indexing basics for SQL Server, and on May 14th…

4 weeks ago

Fabric Mirroring doesn’t start copying Rows

A short blog post about an issue with Fabric Mirroring (with Azure SQL DB as…

2 months ago

Webinar Series – SQL Server Indexing

I'm starting a webinar series about SQL Server indexing with the fine folks of MSSQLTips.com.…

3 months ago