The dedicated development model allows each developer to work on a personal copy of the database and commit changes to a shared source control repository.

When you link a database to source control using the dedicated model in dbForge Studio for SQL Server, a local copy of the database is not created automatically. Each developer must manually create their own database—either on a local machine or a remote server.
1. Each developer installs dbForge Studio for SQL Server on their machine.
2. One developer links a database to version control and makes the initial commit, selecting the Dedicated development model.
3. Other developers retrieve the database using one of the following methods:
Once each developer has linked their database copy to the repository, the typical workflow is:
1. Get the latest changes from the repository.
2. Make changes to the database.
3. Commit the changes back to the repository.
Note
Always get the latest version of the database before making changes. This helps prevent conflicts with updates from other developers.
All changes committed to the repository are stored and can be reviewed at any time.
For more information, see View Source Control history.
If multiple developers modify the same object, a conflict may occur.
For instructions, see Resolve conflicts.
The table describes the benefits and drawbacks of the dedicated development model.
| Benefits | Drawbacks |
|---|---|
| Developers work in isolated environments, reducing the risk of overwriting each other’s changes. Complex changes can be made safely without disrupting other developers’ work. All changes are tracked and visible, improving collaboration and accountability. |
Each developer must maintain a local copy of the database, which can increase setup and maintenance overhead. |