We are glad to announce that the ApexSQL Source Control 2015 R3, with the amended shared source control model and support for Perforce is available for download.
Since a shared model implies that users are working with the same shared database, we opted for the solution to store the information about the current state of objects in a shared database itself or a database selected by the user during the process of linking database to source control, making it unnecessary for the add-in to contact the source control repository for every action executed against objects.
We use this set of objects to monitor who does what in a database, and the tool will communicate with source control only when a user actually commits his changes or wants to see the history of the committed changes.
We also introduced policies as a feature that will provide users with an option to decide whether they want to enforce some predefined rules in the database development process. For example, when the Check out before edit policy is set to true for a database, a user will be forced to check out an object before he will be allowed to apply any change to it.
Among others, there is the policy that force the logging of every single change made to the database in a dedicated table, so the information about who, when and where performed something in the database can be easily tracked.
A locking mechanism is implemented with a purpose to prevent any tampering with the locked objects, until the lock is in place.
To make all this work, the add-in creates the following objects in the mapped database itself or any other database on the server, depending on the user’s choice:
ApexSQL_SC_ObjectsTable – Stores information about the state of the object (IsCheckedOut, IsEdited…)
ApexSQL_SC_PoliciesTable – Stores information about the current state of the policies
ApexSQL_SC_LogTable – Stores add-in’s log information
ApexSQL_SC_UsersMappings – Stores users with linked info of a database
ApexSQL_SC_UpdateObjectProcedure – Stored procedure used for access control via updating the ApexSQL_SC_ObjectsTable
ApexSQL_SC_Trigger – Database trigger for monitoring and logging changes and for applying database policies
We decided to leave the access control to the users themselves, in order to allow them to decide who owns the permission to change the data stored in these ApexSQL Source Control proprietary objects. As an example, if a database admin wants to prevent anybody else but himself to change the database policies, he can set the read only rights to the ApexSQL_SC_PoliciesTable for all others.
The ability for users to execute actions against multiple objects is added in the Action center.
Another addition is added – an option for users to see the entire changesets history of the SC project, including the ability to see all objects committed in a single changeset or the individual object changes.
January 30, 2015
