Progress
Programming
Handbook
Updating Browse Rows
By default, Progress handles the process of updating data in an updatable browse. Assuming that the browse starts with the record in NO–LOCK state, Progress follows these steps:
- On any user action that modifies data in an editable browse cell, Progress
re-gets the record with a SHARE–LOCK. (No other user can change the data.) If the data has changed, Progress warns the user and redisplays the row with the new data.
- When the user leaves the row and has made changes to the row, Progress starts a transaction (or subtransaction) and gets the record from the database with EXCLUSIVE–LOCK NO–WAIT. If no changes were made, Progress does not start a transaction.
- If the GET with EXCLUSIVE–LOCK is successful, Progress updates the record, disconnects it (removes the lock), ends the transaction, and downgrades the lock to its original status.
- If the get with EXCLUSIVE–LOCK fails, Progress backs out the transaction, displays an error message, keeps the focus on the edited row, and retains the edited data.
The 4GL programmer also has the option to disable this default behavior and programmatically commit the changes by way of a trigger on the ROW–LEAVE event. First, you must supply the NO–ASSIGN option in the DEFINE BROWSE statement.
The following code example shows how to use a ROW–LEAVE trigger:
The ROW–LEAVE trigger checks for a special condition where the new data should not be committed to the database. If it encounters such data, the trigger is canceled without any writes taking place. If the data is valid, the GET CURRENT statement is used to re-get the current record with an EXCLUSIVE-LOCK NO–WAIT. It also uses the CURRENT–CHANGED function to ensure that another user has not changed the record since the query first retrieved it. Note that the lock must be downgraded manually at the end of the trigger with another GET CURRENT statement.
Copyright © 2004 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095 |