Change Control in Application Designer
It’s a common scenario that a group of 3 or 4 members in a team will be working on the same “project” present in the Application Designer. In such scenarios, it is possible for a team member to erase the changes made by another team member on an object. For e.g. if a team member “EMP0001″ is working on a SQL view or in a step in an Application Engine, made some changes to it and saved it, there is every possibility that another team member “EMP0002″ accessing the same object to which “EMP0001″ made the change and making some changes to it.
A classic scenario is “EMP0001″ adds a step called “STEP01″ into an application engine and saves it. Now the team member “EMP0002″ deletes that step. How will the team member EMP0001 ensure that his changes are tracked and are protected from any extraneous changes without his/her knowledge.
This is how we can do it. There is something called “Change Control” present in the App Designer. It will be available under the “Options” tab in the toolbar. If you click Change Control for the first time, you can see two options – View History, Administrator.
If you click on the Administrator, you will notice three options that are primarily checkboxes – Change Control Locking, Change Control History and Lock All Definitions. By Default they will be unchecked and the third option will be grayed out.
Check both the options namely Change Control Locking as well as Change Control History. Once you do it, the system will ask you to log out and login again. I assume here that your login has Adminstrator access. All other users of the App Designer should also logout and login again. If you logout and login again, you can see some extra symbols like “LOCK”, “UNLOCK” etc in the toolbar now.
Now whatever object that you access will be read only. If you want to make changes to the object, you will have to lock the object. This can be done by right-clicking on the object and selecting “Lock”. Once you have locked the object, you can make changes to the object and save it. During locking, a display window will be prompted asking you to enter your comments. Through this, a history is maintained as to who made changes to the object, when and why?
The best part is yet to come. Say if team member EMP0001 locked an object, if EMP0002 logs into the same project, he can see a “Lock” symbol on the object locked by EMP0001 along with the userid who locked it in brackets, which in our case is (EMP0001). So EMP0002 will know that EMP0001 is working on it. It is possible for EMP0002 to unlock the object locked by EMP0001. You can ask me whats the big idea. The idea is the changes are tracked now. Now EMP0002 can check the history log before he/she makes the changes.
In the classic scenario (App Engine Step example) that I explained before, EMP0001 can lock the project itself. So whatever changes EMP0002 makes to the project, actually wont get reflected into the project unless and until EMP0002 unlocks the project. So even if EMP0002 deletes the step STEP01 inserted by EMP0001, the system will allow him/her to delete. But actually the change will not be reflected in the project. Through this, the user EMP0001 protects his/her object from unnecessary encroachment. 
