Support Center

Working with migration scripts

Last Updated: May 01, 2014 09:21PM AEST
This article has moved to a new home. For up-to-date documentation please continue reading at

Deploy-Once migration scripts are a first-class artifact of your project, responsible for the entire deployment of your database. Migrations use imperative deployment, as each change is deployed statement-by-statement.

In this regard ReadyRoll differs to the DataDude/SSDT database projects, which use declarative deploymenta method that involves comparing the project to the target database at deploy-time and generating a migration script to synchronise the changes.

Here are a few things to bear in mind when working with Deploy-Once migration scripts:
  • As the name suggests, Deploy-Once scripts are intended to be executed a single time only against a target database.: if you have used a migration script to add a column to a table on your Production server, you should not remove or change the script that performed the change but instead add a new script to the project to drop the column. 
  • Further to the previous point, it is not recommended to make changes to or delete scripts from your project that have already been applied to other databases in your environment (including those of other developers). As a rule of thumb, avoid changing scripts that have already been checked-in to source control.
  • If you want to perform an action with every deployment of your database, try using a Pre or Post-Deployment script instead. ReadyRoll includes sample scripts in the project template (including a Pre-Deployment script that creates the database if it doesn't exist). Bear in mind that you may encounter undesired behaviour if you split inter-related objects between the Deploy-Once and Pre/Post Deployment subfolders.
  • The Xml fragment in the header contains a unique identifier for the migration (ie. <Migration Id="{UniqueIdentifier}"/>). ReadyRoll uses this GUID to ensure that the script is executed a single time against the target database. Please be sure not to remove this comment, as this may result in your script being executed more than once against your target database. 
  • Deploy-Once scripts can be renamed at any time, even if the script has already been deployed. This is possible because the script's unique identifier is contained within the script itself and not in the filename.
  • If you make a change to a Deploy-Once script, performing a Build within Visual Studio will test that the change is not only syntactically correct, but that it is also imperatively correct, i.e. that the script will have the intended effect when deployed to the target database.

    ReadyRoll does this by executing your script against the Shadow database; a separate copy of your database built solely from your Deploy-Once scripts. It then validates that your Schema Object declarations are in-sync with your Shadow database. Note that the Sandbox database is left intact during a build (only the Deploy action modifies your Sandbox).


Working with pre-scripted T-SQL


If you’ve already got some scripts written, or if you need to deploy scripts provided by a vendor (eg. ASP.NET Membership Provider object creation scripts), simply create a new project and then add a new Deploy-Once script file.

Paste the T-SQL into the new script, and then click Deploy Project or, if the objects have already been created in the target database, click Mark as Deployed to prevent the script from being re-executed.
seconds ago
a minute ago
minutes ago
an hour ago
hours ago
a day ago
days ago
Invalid characters found