Shared model

In a shared development model, every developer collaborates on the same database and repository, ensuring they work with the latest version.

Shared Dev Model

Setup

Firstly, all developers install dbForge Studio for SQL Server on their machines so that they can all commit their changes. Then, any of them must link the database to version control and make the initial commit. When connecting the database to a repository, it is required to specify the shared model mode.

Workflow

Once the database schema has been committed to version control, all developers can start making changes.

The workflow is as follows:

There’s no need to update the database with the latest changes from version control because all the changes are already in the database that are being developed.

History

The repository contains all changes made to the database objects. For more information about the history of changes, see View Source Control history.

Conflicts

If several developers make changes to the same object, only the changes made by the last developer will be saved to the database. Detecting the changes the other developer was trying to make to this object is not possible. That is why using the dedicated model is a better practice.

Get latest

There is no concept of getting remote changes in the Shared development model since all developers work on the same database and repository. Consequently, all modifications are directly applied to the shared database. Once a change is committed to the repository, it is already in the database that all developers are using. Therefore, there’s no need to fetch remote changes because the most recent version control updates are already available in the shared database environment.

Benefits

A shared model requires only a single development database, reducing the need for multiple instances of SQL Server.

Drawbacks

There is no secure method way to test changes in isolation.

Switch to dedicated development

1. Unlink the database from source control.

2. Create an empty database, which will be your dedicated copy.

Note

For easy identification, you should name the database something similar to the database you’re about to copy.

3. Link the created database to the source control repository to which the shared database is linked.

4. Get the latest changes to update your dedicated copy with the changes from the original database.

Want to Find out More?

Overview

Overview

Take a quick tour to learn all about the key benefits delivered by dbForge Studio for SQL Server.
All Features

All features

Get acquainted with the rich features and capabilities of the Studio in less than 5 minutes.
Request a demo

Request a demo

If you consider employing the Studio for your business, request a demo to see it in action.
Ready to start using dbForge Studio for SQL Server?