Locks Held on Displayed Data
By default, Vision does not lock the data that a user is displaying on an Update frame. This means that multiple users are allowed to browse and update the same data at the same time. The risk, of course, is that one user can overwrite data just entered by another user.
You can change the default so that Vision holds a lock on the displayed data. The frame behavior Locks Held on Displayed Data controls locking. There are three choices for this frame behavior:
• None
• DBMS
• Optimistic
This frame behavior applies only to Update frames.
DBMS or Shared Locking
DBMS, or shared, locking means that other users are blocked from changing the selected data until the first user selects Save or otherwise releases the lock. The other users can select the same displayed data, but cannot update it until the first user has saved any changes.
If you design your application so that Vision holds shared locks, the displayed data is locked when the user selects Go. The locks on the Master table data are dropped when a user:
• First selects Save
• Moves past the last selected Master table row by selecting Next
• Selects End to leave the query or the frame
• Selects a menu item that calls a browse frame. The select loop of a browse frame issues a commit that releases the locks, including the locks on the calling frame's data.
Be aware that shared locks can result in deadlock when multiple users hold a shared lock on the same data and each selects Save. For information on how Vision handles deadlocks, see
How Vision Handles Deadlocks.
Optimistic Locking
If you use optimistic locking, Vision holds no locks while viewing data. When a user (user1) tries to save a record, Vision checks whether the record has been retrieved and updated by another user (user2) since user1 retrieved it from the database. If the record has been updated by user2, user1's changes are not saved. If the record has not been updated, user1's changes are saved. Optimistic locking depends on Vision using columns in your database tables to track row updates.
To use optimistic locking, you must specify the columns for Vision to use for tracking when the row was last updated. Each column can contain one of the following types of information:
• A date/time stamp, showing when each row of the table was last updated
• An update counter, or sequence value, which is incremented each time the row is updated
• The name of the user who last updated each row
To use one or more of these types, the recommended combinations are:
• Date/time stamp column alone
• Date/time stamp column, with the user name. This adds an additional check in case more than one user is updating the data at the same time
• Update counter column alone. An update counter is sufficient, but you can also add a username if you would like this information for tracking purposes
Note: A user name by itself does not provide a sufficient check.
These columns can be displayed on your form or they can be hidden columns. They must exist in your database tables.
Specify the columns on the Locks Held on Displayed Data pop-up, as shown in the following figure. (See the directions in
Change a Frame Behavior Specification to get to the pop-up.)
After you have specified the column names, Vision automatically uses the optimistic concurrency in the generated code. When the code is generated, the date/time stamp column is set to 'now', the user name column is set to user and the update counter column is set to 0. Every time a user updates the row, the date/time stamp column is set to 'now', the user name column is set to user and the update counter column is set to the previous value plus 1.
