In a shared development model, every developer collaborates on the same database and repository, ensuring they work with the latest version.
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.
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.
The repository contains all changes made to the database objects. For more information about the history of changes, see View Source Control history.
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.
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.
A shared model requires only a single development database, reducing the need for multiple instances of SQL Server.
There is no secure method way to test changes in isolation.
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.