Applies to
ApexSQL Source Control
Summary
This article gives answers to most frequently asked questions related to Database policies implemented in the shared development model.
Optional policy
All of the following question and answers apply only to the Option policy
Q: Are object status icons shown in the Object Explorer pane?
A: Yes, object status icons are shown no matter which policy is active. Check Object status icons and visualization for more details.
Q: Is it possible to edit an object without checking it out?
A: Yes, no checkout is required prior to editing any object.
Q: Is it possible to check in an object without being checked out?
A: Yes, an object can be checked-in, even without being checked out previously, and the changes will be submitted to the repository
Q: Is it possible to edit an object that is previously checked out by another user?
A: Yes, it is possible. While the Optional policy is active, and an object is checked out by another user (User A), it can be edited (by User B). The checkout made by the initial user (User A) will be overridden with the checkout of newest user who edited the object (User B). After the last edit, the object will be marked as checked out and edited by the last user who edited the object (User B).
Q: Is it possible to edit and check-in an object that is already checked out by another user?
A: Yes. After an object is edited, it will be shown as checked out and edited by the user who performed the edit operation which means that the previous checkout (made by another user) will be overridden. The object can then be checked in using the Check in command from the right click context menu in the Object Explorer pane, or through the Action center tab
Q: What happens when a user attempts to checkout an object that is already checked out by another user?
A: When checking out an object that is already checked out by someone else, the following dialog appears:
Permissive policy
All of the following question and answers apply only to the Permissive policy
Q: What happens if a developer tries to edit an object without checking it out first?
A: In case the Permissive policy is enabled, an object must be checked out before editing.
If the user tries to edit without checking out an object, the following warning message appears:
Q: Is it possible to check in an object, checked out by another user?
A: By default, it is not possible. However, it is possible if the Enable committing other users changes option is checked in the add-in options:
Q: Is it possible to checkout an object checked out by another user?
A: Yes, it is possible. A dialog appears informing the user that an object was previously checked out, but the user can proceed with the new check out, despite the warning
Restrictive policy
All of the following question and answers apply only to the Restrictive policy
Q: Why can’t I checkout an object, the menu item is disabled?
A: The Check out option is disabled, because the restrictive policy requires checkout with lock. The disabled Check out option is validated with the appropriate message when hoovering the Check out menu item:
The message says: The object cannot be checked out when the Restrictive policy is active
Q: What happens if I attempt to edit an object that I haven’t yet checked out?
A: The following warning message appears in case the user tries to edit an object, that is not yet checked out.
It is a requirement for an object to be checked out, before editing
Q: Is there a way for a conflict to appear while some of the policies are active?
A: No, this is not possible since database policies are implemented in the shared development model. The shared model means that all users are working on a same database hosted on a single SQL Server instance. All changes are executed against a database, before they can even be considered for committing to source control. With that being said, changes made by one user can be overridden by changes made by another user, but no conflicts can appear.
Usage scenarios and results by policy
Optional
| Checked in | Edited | Checked out | Checked out with lock | |
| Edit | OK | OK | Warning that an object is checked out and that it cannot be edited by another user | |
| Check out | Warning that an object is edited and a confirmation for a check out | Warning that an object is checked out and that the checkout will be overridden | An object checked out cannot be checked out by another user | |
| Undo checkout | N / A | N / A | A checkout can only be undone by the original user who checked out the object | |
Permissive
| Checked in | Edited | Checked out | Checked out with lock | |
| Edit | Warning that that an object must be checked out before editing | Warning that an object is checked out and it cannot be edited by another user | ||
| Check out | OK | Warning that an object is edited and a confirmation for a check out | Warning that an object is checked out and that the checkout will be overridden | An object checked out cannot be checked out by another user |
| Undo checkout | N / A | N / A | A checkout can only be undone by the original user who checked out the object | |
Restrictive
| Checked in | Edited | Checked out | |
| Edit | Warning that an object must be checked before editing | ||
| Check out | OK | Warning that an object is edited and a confirmation for a check out | An object checked cannot be checked out by another user |
| Undo checkout | N / A | N / A | An object must be checked out by the user who wants to perform the undo operation |
