Redgate Change Control 4

Redgate Change Control using SQL Server

In v5, Redgate Change Control has been renamed to Flyway Desktop. Check out the latest documentation at https://documentation.red-gate.com/fd


Redgate Change Control helps you version control and prepare deployments for SQL Server databases. 

SQL Server projects in Redgate Change Control are currently in Preview and are not fully supported.

Demo of Redgate Change Control in action with SQL Server

Watch this 16 minute video to see how to capture database changes from SQL Server using Redgate Change Control. The video steps through creating a new project and describes how to use the schema model and how to generate migrations. You'll learn how to link a development database, configure a shadow database, and create a baseline script. 

Compatible SQL Server versions

Redgate Change Control is compatible with the following versions of SQL Server:

  • SQL Server 2008 and higher
  • Azure SQL Database
  • Azure SQL Database Managed Instances

Available Authentication 

Database connections in SQL Server projects in Redgate Change Control can be configured to use:

  • Windows Authentication
  • SQL Server Authentication
  • Azure Active Directory Integrated Authentication
  • Azure Active Directory Password Authentication
  • Azure Active Directory Universal with MFA (Multi-Factor Authentication)

To configure Azure Active Directory Universal with MFA, see Using Azure Interactive Authentication.

Permissions needed

Redgate Change Control uses our SQL Compare technology behind the scenes to understand the differences.  Please review the permissions needed

Repeatable migrations

Flyway supports repeatable migration scripts for programmable objects, such as stored procedures, views, and functions.

Redgate Change Control currently defaults to generating programmable objects as versioned migration scripts for all new projects. Although Redgate Change Control is capable of generating repeatable migration scripts for programmable objects, we currently recommend that you leave this option disabled when working with SQL Server projects.

This recommendation is in place because some programmable objects in SQL Server, such as views, do not support deferred name resolution. This means that repeatable migration scripts for programmable objects must be able to execute in a custom order based on the dependencies between these objects. In some situations, such as views with circular dependencies, custom scripting must be used. 

The Redgate team is currently research the best way to implement custom execution ordering for repeatable migration scripts.

If you are interested in this feature and would like to participate in this research, share your details via this quick survey. 


Didn't find what you were looking for?