To allow multiple users to successfully use your application, you must choose the type of locking used as well as handle any error conditions that occur as a result of multiple users working with the same record.
The following table lists the scenarios that can occur. The events listed happen in order from left to right. For example, in the first row User A passively locks a record, then User B passively locks the same record. User A deletes the record, then User B changes the contents of the record and saves the record. The changes User B made will be saved.
![[spacer]](1p.gif){kind=small}
|
Case |
User A |
User B |
User A |
User B |
Result |
|---|---|---|---|---|---|
|
1 |
Passively locks a record. |
Passively locks the same record. |
Deletes the record. |
Changes the contents of the record and saves the changes. |
The changes User B made will be saved. |
|
2 |
Passively locks a record. |
Passively locks the same record. |
Changes the contents of the record and saves the record. |
Deletes the record. |
The record will be deleted. |
|
3 |
Passively locks a record. |
Passively locks the same record. |
Changes a field and saves the record. |
Changes a different field and saves the record. |
Both changes will be saved. |
|
4 |
Passively locks a record. |
Passively locks the same record. |
Changes a field and saves the record. |
Changes the same field and attempts to save the record. |
User B will get an error indicating the record changed. User B’s changes won’t be saved. |
|
5 |
Passively locks a record. |
Passively locks the same record. |
Deletes the record. |
Attempts to delete the record. |
User B will get an error indicating the record is missing. |
|
6 |
Actively locks a record. |
Passively locks the same record. |
Keeps the active lock. |
Attempts to delete the record or change a field and save the record. |
User B will get a record locked error. The record won’t be deleted or the changes won’t be saved. |
|
7 |
Actively locks a record. |
Passively locks the same record. |
Deletes the record. The active lock is released. |
Changes the record and saves it or deletes the record. |
If user B changed the record and saved, the changes will be saved. If User B attempts to delete the record, User B will get an error indicating the record is missing. |
|
8 |
Actively locks a record. |
Passively locks the same record. |
Makes changes and saves the record. The active lock is released. |
Changes the record and saves it or deletes the record. |
If User B changed the same field as User A, User B will get an error indicating the record changed. User B’s changes won’t be saved. If user B changed different fields, the changes will be saved. If User B deleted the record, the record will be deleted. |
|
9 |
Passively locks a record. |
Actively locks the same record. |
Attempts to delete the record or change a field and save the record. |
Keeps the active lock. |
User A will get a record locked error, even though User B’s active lock came later than User A’s lock. |
|
10 |
Actively locks a record. |
Attempts to actively lock the same record. |
|
|
User B will get a record locked error. |
Scenarios 1 through 3 don’t produce any errors. A multiuser application should be able to handle scenarios 4 to 10, alerting users that an error occurred, and allow them to respond appropriately.
|
In the current version of Dexterity, fields with the text control types should not be used in tables that are checked for multiuser error conditions. Records can’t be locked properly if text fields are included in the table. If your application uses text fields, store them in a separate table that won’t be checked for multiuser error conditions. |
The err() function is used to trap errors so the script can deal with the errors that occur. The following examples are the Part Number, Save Button and Delete button scripts for the sample inventory application. They use the err() function to trap and handle errors.