By default, the AVM handles the process of updating data in the records managed by an updateable browse’s query. Because you should normally create applications that do not have a client-side dependency on a direct database connection, it is not advisable for you to define browses directly against database tables or to update database tables directly through a browse. Therefore, the default update behavior is described here to make you aware of what the AVM does when you are browsing a database table, not to recommend that you take advantage of it. Some of these steps might not be completely clear to you until you read Manage Transactions but it gives you an overview of the steps.

Assuming that the browse starts with the record in NO-LOCK state, the AVM follows these steps:

  1. On any user action that modifies data in an editable browse cell, the AVM again gets the record with a SHARE-LOCK, which means that no other user can change the record. If the data has changed, the AVM warns the user and redisplays the row with the new data.
  2. When the user leaves the row and has made changes to the row, the AVM starts a transaction (or subtransaction) and gets the record from the database with EXCLUSIVE-LOCK NO-WAIT, which means that no other user can lock the record in any way. If no changes were made, the AVM does not start a transaction.
  3. If the GET with EXCLUSIVE-LOCK is successful, the AVM updates the record, disconnects it (removes the lock), ends the transaction, and downgrades the lock to its original status.
  4. If the GET with EXCLUSIVE-LOCK fails, the AVM backs out the transaction, displays an error message, keeps the focus on the edited row, and retains the edited data.

You also have the option to disable this default behavior and programmatically commit the changes by way of a trigger on the ROW-LEAVE event. To do this, you must supply the NO-ASSIGN option in the DEFINE BROWSE statement.

If you define your browses against temp-tables, as you are doing in the OlineBrowse of the test procedure, then there are no record locks and no possibility of contention with other users for the records in the temp-table. Therefore, you can let the AVM update the temp-table by defining the browse without the NO-ASSIGN keyword and then take care of updating the database from the temp-table yourself. You learn how to do this in Create and Use Dynamic Temp-Tables and Browses.