A shared development model allows every developer to work on the same database and repository that contains the most recent database version.
Firstly, all developers install dbForge Source Control on their machines so that they can all commit their changes.
Then, any of them needs to link the database to version control and make the initial commit.
It is required to specify the Shared Model mode when you link a database to a repository.
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 in updating the database with the latest changes from version control, since all the changes are already in the database where they are developed.
The repository contains all changes made. To learn how to view changes history for the entire database or separate database objects, refer to the Viewing Source Control history topic.
If two developers make changes to the same object, only the changes made by the last of them will be saved to the database. There is no way to detect what changes another developer was trying to make to this object. That is why using the Dedicated model is a better practice.
Shared model requires only one development database, i.e. there are fewer instances of SQL Server required.
There is no safe way to test changes in isolation.
Unlink the database from source control.
Create an empty database. It will be your dedicated copy.
For easy identification, you should name the database something similar to database you’re about to copy.
Link the created database to the source control repository that the shared database is linked to.
Get the latest changes to update your dedicated copy with the changes from the original database.