SQL Source Control 3.6 and later includes a beta version of the new Migrations V2 functionality. This is an improved version of the V1 migration script functionality introduced in SQL Source Control 3.0, and works quite differently behind the scenes.
Because Migrations V2 is still in beta, SQL Source Control uses Migrations V1 by default. To use Migrations V2, you need to enable it in the engine and comparison options.
- Why migration scripts are useful
- Enabling the Migrations V2 beta
- Disabling the Migrations V2 beta
- How V2 migration scripts are used in deployment
- Setting the location of the temporary database
- Example V2 migration scripts
- Example: renaming a table without data loss
- Example: writing a V2 migration script that affects objects not yet in the target database
- Packaging V2 migration scripts for Deployment Manager
What's new in Migrations V2
Migrations V2 supports:
- all source control systems (including Git and Mercurial)
- branching and merging
- better integration with CI systems for automated deployment
- SQL Azure databases
Unlike V1 migration scripts, V2 migration scripts don't need to be saved in a separate folder in the repository. Instead, when you commit a migration script, it's added to a table-valued function in the database. For more information, see How V2 migration scripts are used in deployment.
What do you think?
We want to hear what you think about Migrations V2.
- Suggest and vote for ideas on the SQL Source Control user suggestions forum
- Discuss the new migrations feature in the Migrations V2 Google group
- Report bugs to support
- If you find mistakes in this documentation, or it doesn't answer your questions, use the "Mistake on this page?" email link at the bottom of each page