Skip to content

Multi-User Considerations

When multiple users are accessing (more particularly, writing to) the same database, it is essential that they do not overwrite each other's work indiscriminately. It is equally essential that the work of each is not just ignored by the system or allowed to "fall through the cracks" in some way. Very strong safeguards against this are available in DataFlex, and if you use properly constructed views containing data-entry and data-set objects, they are automatic.

The following commands will only function under multi-user runtime systems. They have no effect in single-user runtimes, but it is recommended that full multi-user provisions be made in all programs to provide for the eventuality of a program's being run among multiple users. These commands are explained in detail in Multi-User Command Group.

Commands

  • lock
    Prevents other users from locking or writing to tables. Remains in effect until the user issuing the lock issues an unlock.

  • reread
    First issues a lock, then reads data from any table with an active record buffer. Used without an argument, reread affects all open tables. Alternatively, just the table to be affected can be named on the reread command line.

  • unlock
    Restores the system to normal Read/Write status.

DataFlex handles the majority of multi-user issues automatically via data dictionary objects (DDOs). However, there may be times when you want to perform "raw" database I/O with procedural commands. In these situations, DataFlex assists you by enforcing sound multi-user coding techniques throughout every program.

The rule of writing proper multi-user code with DataFlex is to never perform database edits in a non-locked situation. Moreover, to ensure database integrity, reread should be used prior to any updates to the database to ensure that database changes by all users are mutual rather than exclusive.

Example of Proper Multi-User Coding

open vendor
find gt vendor
reread
move "TEST" to vendor.vendor
save vendor
unlock

This example illustrates proper multi-user coding. It finds a record, then rereads, which does a lock and then refinds the record. Then it does the edit (move command), saves only when locked, and unlocks when completed.

Faulty Example 1

open vendor
find gt vendor
move "TEST" to vendor.vendor
save vendor

In this example, no lock (or reread) is applied. Another user might edit the database at any point between the find and the save. Deletion and subsequent replacement of the record could cause the wrong record to receive the edit. This is a definite possibility in a busy multi-user site. If the column(s) being edited are included in indexes, then the indexes concerned may also be corrupted.

Faulty Example 2

open vendor
find gt vendor
lock
move "TEST" to vendor.vendor
save vendor
unlock

In this example, a lock is done instead of a reread. Here, the danger described above is confined to the narrower range between the find and the lock, but it remains a possibility. Reread, which refinds the record, obviates this possibility.

No matter how fast your system is, there is always that small amount of time between the find and the lock. Both these situations produce a runtime error 4155: "Edit requires reread or find during lock."

Error 4155 is triggered whenever an edit to an existing record happens in a non-locked state, or when the record was found in a non-locked state and no reread took place. (Note: the error is not triggered when a single-user runtime is in use, but good programming practice is to always code for multi-user for maximum portability.) The following code would not trigger the error:

open vendor
lock
find gt vendor
move "TEST" to vendor.vendor
save vendor
unlock

In this example, since the find takes place in a locked state, no reread is required and the edit still happens while locked. The following code will give the error:

open vendor
lock
find gt vendor
unlock
move "TEST" to vendor.vendor
save vendor

Even though the find took place in a locked state, the edit to the record buffer violates multi-user integrity, being performed in an unlocked state.

Handling Error 4155

What do you do if you run a program and get this error message? You must ensure that, throughout your application, you always follow the rules of multi-user integrity.

See Also