How can we help you today? How can we help you today?

Can SQL Data Compare commit changes to source control repositories?

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.

BobGood
0

Comments

5 comments

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


    AlexYates
    0
  • BobGood
    Alex, Thanks for the reference. While similar the scenario was different. Regards, Bob Good
    BobGood
    0
  • 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.)
    Jessica R
    0
  • 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.
    BobGood
    0
  • 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.
    AlexYates
    0

Add comment

Please sign in to leave a comment.