Use a scritps folder source with migration scripts?

mmchenrymmchenry Posts: 9 Bronze 1
edited November 1, 2012 5:09PM in SQL Compare Previous Versions
It seems like I'm not the only one confused about migration scripts. There's very little documentation or guidance available. From what I gather in reading a bunch of forum posts here, it seems like migration scripts only work with with a source control repository as the compare source.

Is this actually the case? And if so, can someone explain why?

Our normal build process copies the scripts folder from TFS into the build drop folder. From there we can copy the drop folder to any number of other servers and run a batch file that uses command line SQL Compare to deploy the DB changes. These other servers could be at sites that don't have access to the source control repository. If migration scripts really are limited to the source control repository, then it don't really see how it can be used in a general deployment strategy. Hopefully, I'm just not understanding it correctly.

Comments

  • Hi,

    Thanks for your email. I think your understanding is correct.

    We acknowledge that migration scripts are confusing and the current implementation is flawed in as much as it requires access to the source control system. The reason is that in order to fill in the gaps between the migration scripts, the SQL comparison engine needs to fetch the before and after states, which it currently fetches from source control.

    We have just begun a project to remedy this. The solution will be to store the before and after states alongside the migration scripts themselves. Once this new architecture is complete, which is penned for the first half of next year, you will only need to reference the migrations folder (which you should check out as part of your build process) to leverage migration scripts. So if you have the migration scripts folder in your remote site, your batch file would use sqlcompare.exe and a switch to reference the migrations scripts folder.

    Apologies that this isn't the way it should be right now, but hopefully we can remedy this in the coming months.

    Kind regards,

    David Atkinson
    Product Manager
    Red Gate
    David Atkinson
    Product Manager
    Redgate Software
  • mmchenrymmchenry Posts: 9 Bronze 1
    Thanks for the quick reply. I figured it was something like that.

    We can work around the issue for now with some manual scripting in the build process, but I'm looking forward to being able to use the migration scripts feature in the upcoming release.

    Thanks for the preview of what's coming. A lot of companies aren't that open with their plans.
Sign In or Register to comment.