These pages cover SQL Source Control 3. Documentation for older versions is also available.

Skip to end of metadata
Go to start of metadata

There are two common ways for teams to develop databases:

  • Dedicated
    Each developer works on their own copy of the database
  • Shared
    Developers work on a single database

Some development teams use variations or combinations of these models. For example, a large team might use more than one shared development database.

Dedicated development 

Each developer works on their own copy of the database. The copy can be local or on a central server, but local copies provide better performance. 

This approach mirrors application development. Each developer makes changes independently, tests them, and commits them to source control once they're confident in the changes. After the changes are committed, other developers can apply them to their copy of the database.

Because each developer is working in an isolated environment, there's no risk of accidentally overwriting someone else's changes. You're free to develop complex changes that may cause other parts of the database or the application to break. If something does break, there's no impact on other developers.

Like shared databases, dedicated databases don't contain any table data (unless you've source-controlled your static data). This means, for example, that external consultants with their own dedicated database copy won't have access to sensitive table data.

Shared development

Each developer works on a single shared copy of the database. This is usually created from a backup of the production database. When a milestone is reached, a deployment script is created to migrate the final state of the database to a test database.

Because the changes are made directly to the database itself, you don't need to use the Get latest tab. There are no changes to share or get, and the database always has the most recent changes.

However, there's no safe way to test changes in isolation, and developers may overwrite each others' changes by mistake. Additionally, unless you create a new database to log changes, information about who made changes is eventually lost.

Working with SQL Source Control

SQL Source Control is compatible with both models.

Setting up SQL Source Control for a dedicated development

  1. One developer links their copy of the database to a location in source control for the first time.
  2. The developer commits the objects.
  3. The other developers link their own copy of the database to that source control location.

    Alternatively, they can create a new blank database and link it to the database in source control, or restore a backup of the development database. Restoring a backup has the advantage of including any necessary data.

  4. Each developer gets the latest version of the database.

For more detailed setup instructions, see Worked example - Subversion or Worked example - Team Foundation Server.

Setting up SQL Source Control for shared development

  1. One developer links the shared database to a location in source control for the first time.
  2. The developer commits the objects.
  3. In SQL Server Management Studio, the other developers connect to the database and link to source control.

For more detailed instructions, see Linking a database to source control.

Switching to dedicated development

If you're using the shared development model, it's simple to switch to the dedicated model. To do this, each developer on your team needs to:

  1. Unlink the database from source control.
  2. Create a new empty database. This will be each developer's dedicated copy.


    For easy identification, you should name the database something similar to database you're about to copy; for example, DatabasenameCopy or DatabasenameJane.

  3. Link the new database to the source control repository that the shared database was linked to.
  4. Go to the Get latest tab and get the changes.
    The new database is updated with the changes from the original database, creating a dedicated copy.
  • No labels