Migration Scripts

To learn more about migration scripts including versioned migration scripts, repeatable migration scripts, treating programmable objects as repeatable migration scripts, undo migration scripts, and the order of execution for migration scripts, please see our page about Migration scripts.

Generate migrations tab

On the Generate migrations tab, you'll be able to see changes that have been made to your development database that are not in your project yet. You can select the changes that you want to import into a new migration script. Stateful objects (eg., Tables) will be put into Versioned migration scripts. Programmable Objects (procedures, packages, views, functions, etc) will be put into Repeatable migration scripts.  Read more about Versioned and Repeatable Migration Scripts above. 

Apply to database tab

On the Apply to database tab, you’ll be able to apply migrations scripts in your Migrations Folder to your development database.  This could come in handy if you want to create a migration script offline and then apply those changes to your development database.  This could be for a complex change that the tool won't generate correctly or for changes to update transactional data that need to be deployed. 

The Apply to database tab is also important if everyone on your team is working on a dedicated development database or you are switching branches.  Pull the latest changes to your Migrations Folder using your version control system and then apply the changes to your development database. 

Viewing all migrations

On the Apply to database tab, use the Show drop-down to change from Pending migrations to All migrations.  you'll be able to see information about all the migration scripts that have been applied to your development database.  You'll also see any pending migrations that are in your Migrations Folder that haven't been applied to the development database yet.  If any migration scripts failed during their execution, these will appear as well.

Some repeatable migrations will also show as superseded.  This means an older version of the repeatable migration was applied, but since then a change has caused the changed repeatable migration script to be re-applied at a later time.    

Development database

A development database is linked to a project for the purpose of generating Migration Scripts. Redgate Change Control enables a connected development experience.  You can make changes directly to your development database, and then when you're ready to commit these to your version control system, use the Generate migrations tab to script these to your project.  

Shadow database

The shadow database is a separate database that is needed in development only.  When you generate migrations with Redgate Change Control, we run the scripts in the project against the shadow database.  Then, we use our Schema Compare for Oracle technology to compare the development database to the shadow database.  This allows us to show you what changes have been made to your development database that have not been imported into your project yet.  

See Shadow Database (or Shadow Schema) for more details.

Baselining

When working with an existing database, you must setup a baseline script that represents the current state of your database.  This is necessary so that we can build the shadow database from scratch when you generate migrations to understand any new changes on your development database that haven't been imported into the project yet.  This is also important so you can spin up new environments in dev and test or deploy to new client sites.  Learn more about how to setup a baseline at Creating a baseline script.