Applies to
Summary
This article explains how the user can commit changes that are made by other users on objects in the database source control.
Description
This database source control tool allows developers to chose in which development model the database will be linked in:
- Dedicated development model – is where database developers are working on the local copy of a database. Other database developers cannot affect changes to objects in a single database until that database developer who changed the object committed that object to the repository
- Shared development model – all database developers are working on one shared database. Unlike the dedicated development model, in the shared development model, objects are simultaneously submissive to change from multiple developers at once
In the database source control, whoever made the change against a database object must commit that change to the source control repository. In the case when for some reason, that cannot be done, those changes are locked for all other database developers working on the same database.
ApexSQL Source Control offers users an option to commit all changes made against a linked database no matter which database developer made them. In this article, the process of allowing other users’ changes to the source control repository will be explained.
Linking databases in the shared development model
The prerequisite to enable this option is that the database is linked to the shared development model.
To link a database in the shared development model, right-click on the selected database in Object Explorer, and choose the Link a database to source control command:
After the connection type is set, under the Development model tab of the Source control setup window, select the Shared development model. This will initiate the creation of a separate database (by default ApexSQL) for storing the framework objects:
For detailed information about how to link a database in the shared development model, see How to implement SQL Server source control using the shared development model.
When the first developer links the database in the shared development model, then all database developers from the team have to link the same database in the shared development model too, before they can start working on it.
This database source control tool offers a lot easier and faster database linking for database developers who work on the same shared database. To learn more about this feature, see How to save time linking to multiple databases by sharing mappings to other team members.
How to allow committing other users’ changes
When working in the shared development model, in the Action center tab, all database developers will see all changes made by anyone from the team working on the same shared database:
If someone tries to commit changes on database objects made by another team member, the following message will appear:
The shown message, as a precautionary measure, suggests to the user that someone else from the team has modified the object. This database source control tool allows developers to commit changes made by other team database developers. However, there’s an option that should be enabled first to make this happen.
To enable users to commit changes made by other users, from the ApexSQL main menu in Management Studio, go to ApexSQL Source Control, and then select Options:
The Options window will be opened:
Switch over to the Administrations tab, and check the Allow committing other users change option under the Misc heading, then click on the OK button to save changes:
This way, at the team level, this database source control tool will allow every team member to commit changes made by any other team members against the shared database.
When this option is enabled, committing the changes of another database developer from the team against objects will be allowed. As soon as the commit goes through, the message in the Action center will indicate that everything is synced:
By default, this option isn’t enabled for a reason. It should only be used in a case e.g. when the database developer, for some reason, is not able to continue his work with the shared database or because her/his shift has ended but changes have to be pushed into production, etc.
