By creating temporary tables, browse mode lets you scan database rows and update their values one row at a time. This feature uses optimistic concurrency control, which holds no locks while you are accessing data. Browse mode requires several steps because it transfers each row from the database into program variables before browsing and updating it.
Because a row being browsed is just a copy residing in program variables, rather than the actual row in the database, the application must ensure that changes to the variables’ values reliably update the original database row. In particular, in multiuser situations, the application must ensure that updates to the database made by one user do not overwrite updates made by another. This becomes an issue whether the application selects one row or several rows at a time from the database. A timestamp column in database tables that can be browsed lets you regulate this type of multiuser updating.
Browse-mode functions also allow an application to update ad hoc queries (queries made while an application is running). Several of these functions return information that an application can use to examine the structure of a complicated ad hoc query to update the underlying database tables.
Conceptually, browse mode does the following:
In an application, implement these three steps as follows:
To use browse mode, the following conditions must be true:
In addition, browse mode requires two DBPROCESS structures: one for selecting the data and another for updating based on the selected data.