Database development policies

Applies to

ApexSQL Source Control


This article explains how to work with the Database development policies feature in ApexSQL Source Control.


ApexSQL Source Control provides a possibility to establish and enforce behaviors among developers regarding source control, for example, mandatory locking of files on checkout. These rules are enforced in ApexSQL Source Control via Database development policies. ApexSQL Source Control has three policies implemented: Optional, Permissive, and Restrictive. The feature is available in the shared database development model only.

Optional policy

This is the policy set by default. When the Optional policy is set, each developer can work on an object without the need to perform a check out or lock before editing:

The optimal policy

If developer A makes changes to an object, they will be overwritten if developer B makes additional changes.

Having the optional policy enabled (which is, in reality, having no policy) requires the team to communicate outside ApexSQL Source Control to avoid overriding each other’s changes.

Permissive policy

By setting the Permissive policy, a requirement is created that each object must be checked out before editing:

How to set the Permissive policy

An object can be checked out from the Object Explorer pane, by choosing the Check out option from the context menu:

How to the check out the object

As soon as an object is checked out, it can be edited. To verify that an object is checked out, note the icon on an object. A blue checkmark indicates that it has been checked out by you:

How looks the icons for the checked out object

If an object is not checked out (while the Permissive policy is active), ApexSQL Source Control prevents any developer from making any changes against it, enforcing the requirement that it must be checked out first.

In such cases, the following warning dialog will appear:

The Post-Save Notifications for the Permissive policy

It is possible to check out an object that is already checked out by someone else.

When checking out an object already checked out by someone else, a dialog appears with the information about the user who checked out an object. To override the check out, click the Yes button:

"Object checked out by SA" message appears

Restrictive policy

The Restrictive policy requires that the object must be locked before editing.

Note: the Lock operation cannot be overridden:

How to set up the Restrictive  policy

While the Restrictive policy is enabled, each developer must check out an object with the lock before editing.

If an object is checked out and locked, a developer who performed this operation against an object is the only one who can edit an object after that.

To perform a check out and lock on an object, right-click it in the Object Explorer pane and select the Check out and lock option from the context menu:

How ti Checked out and lock the object

When an object is checked out and locked, the object icon will be changed in the Object Explorer pane, to reflect the appropriate status:

Icon for the object which is the Check out and lock

If an object is not checked out and locked (while the Restrictive policy is active), ApexSQL Source Control prevents making any change against an object, enforcing the requirement that the object must be checked out and locked prior to editing. The following warning appears:

Post-Save Notifications for the Restrictive policy

If another developer checked out and locked an object, it could not be edited by any other developer after that.

Since the Lock command cannot be overridden, the rest of the team cannot override a lock until it is released by a developer who performed the Lock operation, or until changes made against an object are committed.


Q: What is the scope of a database policy?

A: Database development policies are applied to the entire database.

Q: Is there an option to change the scope of a database policy?

A: Yes, using the Global settings filtering from the add-in options, objects that do not need to be version controlled can be excluded, and such objects will not be affected by database policy settings:

The Global seting tab in the Options window

Q: Do I need to use a database policy if I’m the only one who works on a database?

A: No, database development policies are designed for a team working on the same database.

Q: Is there a way I can set a group of users that must follow the rules set by the database policy?

A: By default, all users are included in the scope of the policy.

Q: Can I apply database development policies while using the dedicated development model?

A: No, database development policies can only be applied if the shared database development model is used.

Q: Is there a quick overview of the status of all objects, so that I can find if an object that I want to work on is checked out or locked, without searching it in the Object Explorer pane?

A: Yes, ApexSQL Source Control has the Object status feature implemented. To see the status of all objects, right-click on a database, and from the context menu, select the Object status option:

How to see the Object status for certain database

A list of all objects that are included in source control will be shown, along with the status of each object and the user who changed the status:

The Object status window