Locking Records

DataView features a locking management for explicitly locking individual records. It is based on the transaction locking of the data base and guarantees the referential integrity of the data model.

With all operations on the DataView user interface, which result in changes in the data base, DataView checks the record concerned for existing locks before executing the operations. If the records are locked, DataView will not allow the current user to execute the operation. If the records are not locked, DataView allows the current user to execute the operation and locks the record concerned for other users as long as the operation is in running.

If you create userexits that access the data base to change it, you have to provide the locking protection. For this purpose, the module dbi provides the functions dal_dbi_lck_elm to lock a record and dal_dbi_fre_lck to unlock all previously locked records.

The record locking is internally realized assigning a keyword to the record. This keyword consists of the identification code of the user (UIC) and the process Id and is entered into the internal system field C_LOCK which is part of any DataView table. To unlock a record, DataView sets the entry in C_LOCK to the value 0 (but not NULL !).

In order to be able to unlock temporarily locked records after a system crash, DataView logs locking in a user specific lock log file for each record. The file can be found in the < lck> directory. DataView creates this file in the initialization phase and removes it when the program is closed normally. If DataView detects old lock log files in the initialization phase, it automatically unlocks all locked records it contains. For in DataView several users can work under the same name at the same time, the name of this file is expanded by the prefix "T_" plus the identification code of the user (UIC) and a letter of the alphabet (e.g. "T_100.A"). This allows a maximum of 26 users to work under identical names simultaneously.

The DataView locking management becomes active for the following operations:

editing records
When editing records each selected record is locked, before it shifts into mask edit state. It remains locked until editing is finished by either storing or discarding (cancel) the changes.

If a record is already locked, it cannot be shifted into mask edit state. This has the effect that records which are being edited by a user, cannot be changed or even deleted by another one.

Temporarily Deleting Records
When records are temporarily deleted, each selected record remains locked until all corresponding delete transactions are finished.

If a record is already locked, no delete transaction can be executed on it. This has the effect that records which are being edited by a user, cannot be deleted.

Creating New Relation Records
When interactively creating new relations records, all selected master records and the parent record of the relation remain locked until the action is finished by either storing or discarding (cancel) the entries.

If a parent record is already locked, the operation cannot be executed. In case of locked master records it can only be executed for the master records that are not reserved. This has the effect that records which are being used as parent or child of a newly entered relation, cannot be deleted.