In any multi-user environment, it is essential that the software protect the activities of one user from adversely affecting another’s work. In MPM, every Task window employs some form of file/record locking. On a network, MPM automatically implements the file/record locking features.
File-Locking MPM will file-lock (lock an entire database so that other users cannot access it) when a user:
Runs utilities such as the Estimating Utilities or the WBS Leg utilities, or
Performs other actions that involve the entire database, such as importing data.
Some windows file-lock while the user is saving data.
Record-Locking — MPM will record-lock (lock a record or row in a database so that other users cannot change that row) when the user chooses to save that row.
In most cases, the file or record is locked for only a moment while the update is being made. For example, when you save a WBS record, the WBS database is briefly locked during the save and then released. If locks were not applied, it would be possible for another user to save the same WBS at another machine. As a result, either a duplicate WBS would then exist or the pointers would become corrupted.
If two users attempt to update the same data simultaneously, MPM notifies the current user that another user is adding or editing the same record.
Some Task windows file-lock entire databases, even entire projects, for a longer period of time. For example, when an estimate reprice is running, the estimate detail (.RRD) and estimate header (.RRH) files are locked and the locks do not come off until the reprice has finished.
The .RRD, .RRH and .WBS files are locked during the following processes:
Estimate Reprice
Estimate Adjust
Date Shift
Rebuild Rollup
Replanning
When MPM displays the "Database Is Busy" message, it means that a user is attempting to lock a file or record that is already locked by another user. This message will continue to display and flash until either the lock is released or the user presses ESC to abort the attempt.
If multiple users are waiting for the same locked file, the first user that attempts to access the file after it is unlocked will get access to the file. There is no first-come-first-served queue associated with a locked file.
If a network seems excessively busy, it is probably because a user is running Estimate Reprice or Estimate Adjust.