Can SQL Data Compare commit changes to source control repositories?

BobGood

Scenario - We have a table of configuration data whose content varies as it gets promoted. We would like to source control environment specific data in a branch separate from where we are source controlling the rest of the database. That way the environment specific entries do not make it to the promotion path.

Can SQL Data Compare commit changes to source control repositories? Is subversion a supported repository where SQL Data Compare can perform a commit?

So far my work around is to compare to a file share and use Tortoise to commit it to subversion.

Jessica R

Sorry that hasn't helped, @BobGood! Would you mind letting us know which part(s) of that article didn't apply? Perhaps we can suggest some alternatives.

(Note: SQL Data Compare can deploy changes to a working folder, but I'm afraid it can't when pointing to a source control repo as the data source.)

AlexYates

Jonathan Hickford covered a similar scenario in this blog post. I hope it helps:

https://www.red-gate.com/blog/database-development/customer-specific-database-deployments

BobGood

Alex, Thanks for the reference. While similar the scenario was different. Regards, Bob Good

BobGood

Jessica, Thanks for answering the question and confirming SQL Data Compare cannot write back to a source control repository. (Although it can write to a working folder which may be under source control.)
The difference in Jonathan's scenario and mine are that I have no way to use filters, deciding what to deploy where, since it is data in the same table object (rather than objects in different schemas) that I want to control by environment.

AlexYates

I implemented a solution that mightmwork for you in part 3 of this series:
https://www.red-gate.com/hub/product-learning/sql-compare/how-to-build-multiple-database-versions-from-the-same-source-using-sql-compare-filters

That solution used a migrations approach to script out the tables that varied per target, but you could do the same for data.

However, a simpler way might be to use the default SQL Source Control functionality to store a "master" static data set, and then manually create copies of the master data set in different directory in source control (away from the SQL Source Control directory) with a copy that you manually update with the data for CustomerA and CustomerB etc. Then your build process can run some PowerShell or something to sub the "master data" with the "CustomerA data" etc before running your SQL Change Automation build and deployment processes.