The basic idea behind all software change management solutions is the concept of having a vault. In order to make a change, one should have permission to access the vault (check-out) and permission to update the vault (check-in). If the vault is open to everyone, there is no audit of the change and no change management.

Most of the common change management software in the market today are based on changes made locally. On a check-out, a copy is created locally and on check-in the updated copy is signed in the vault. This philosophy is excellent when one can work locally on the object with zero interference from others and the system knows about the local copy. For example: work on a design document, write code, compile it locally and then merge it into the signed code in the vault.

This methodology assumes one must get permission from the vault in order to perform the changes, but when doing database development (altering the table structure, modifying the procedure) there is no link between the database and the vault. One can modify the database without getting permission from the vault – which will cause inconsistent data in the SCM repository which you definitely do not want to allow.

Let’s examine the following example of two developers, A and B, working on the same project and both needing to update the same procedure in the database:

            Developer A performs a check-out

            Developer B made changes

            Developer A compiles – overriding changes made by developer B

            Developer A performs a check-in

            Developer B gets the copy within the database (including only changes made by developer A) and performs a check-out and check-in

After both developers update the vault, the changes made by developer B are gone, something you definitely don’t want to happen which is why you have SCM in your project.

dbMaestro TeamWork™, our innovative database version control, solves exactly this problem by forcing the DBAs and developers to perform check-out prior to making changes in the database– and actually enforcing the change process. Now in our previous example, using dbMaestro TeamWork ^TM, developer B cannot work on the specific object in the central resource (the database) while the object has been checked-out by developer A. Only once developer A inserts the new code back into the vault (check-in), can developer B can work on the object as required. TeamWork will force developer B to notify the vault (check-out) in order to work on the object, and thus will not allow the system to enter into a situation in which changes may be lost.

This approach of linking the database development and the vault is unique to dbMaestro TeamWork.