Locking records is used to prevent data changes, on the same record, at the same time, by two or more different users. Optional you can use locks to assure, that a record is only opened by one user at the same time.
Edit Locks
When a record is going to be edited, the application tries to lock the record to the current user. These locks are called "Edit Locks". If the record is already locked by a different user (foreign lock) locking fails. The edited field gets a red border and a message is displayed as tool tip.
You still can edit a field, but changes cannot be written to the database until the foreign lock is released. Locks are checked each time you make changes or if you try to save a record.
If you want to save a locked record
-
...and the foreign lock persists, saving is aborted and a message with information of the foreign lock is shown:
-
...and the foreign lock has been released, the record is reloaded to get the changes, made by the other user.
NOTE: If a field was changed by you and the other user, the new value is loaded and your changes for this field are discarded.
If your SavedialogType is EditedFields a dialog with your (remaining) changes is displayed:
In the case, that all your changes have been discarded by reloaded new values, the following message appears:
Open Locks
Open locks are used to prevent, that a record is opened by two or more different users at the same time.
Open locks are optional and by default deactivated.
To activate open locks, check the UseOpenLock property of an AccessModelNode.
If you try to open a record, that is locked by another user, the following message is shown:
Handling Locks
Locks are written to the database with the following information:
- M4ID of the locked record
- Session ID
- Username
- Start Date
- Alive Data
Session ID And Username
The Session ID is a new generated ID on application startup and identifies the user, who locked the record.
The locking system does not use the username to identify the user, as in some organizations several users share the same user login.
The field "Username" is only used in locking messages.
NOTE: If the application closes by an unhandled exception, records can remain locked after restart and be reported as "locked by someone else",
while the username of this person is your own username.
This happens, because the Session ID is different after restart and it is assumed, that you are a different user.
In this case you have to wait 3 minutes until the lock expires.
Start And Alive Date
Start Date and Alive Date are set to the current date and time, when the lock has been added. While the Start Date is not changed anymore, the Alive Date is updated with the current date every minute. This is done by the application for all locks, with the Session ID of the application.
Removing Locks
Locks are removed, when the record is saved or all changes are undone (edit locks) or the record is closed (open locks).
Also locks are removed, when they are expired. Locks are regarded as expired, if the Alive Date has not been update for a defined number of minutes.
The number of minutes can be set in AppSettings.xml with the LockExpireMinutes property. Default value is 3 minutes.
Expired locks are removed, when the application tries to lock the same record.
Also all expired locks are removed on application startup.
Finally, all locks with the Session ID of the application session are removed, when the application is closing.
This was the last chapter of the M4 Back Office With Standard Components part of the documentation.
You can go on reading about M4 Back Office With Custom Components And Functions.