Previous Next Table of Contents

7. Update issues

Any application that displays database values and allows the user to update them has two problems:

  1. Ensuring that the generated UPDATE statement will really update the row that was displayed and not many other rows in the database.
  2. Ensuring that the affected row has not changed since it was displayed.

The first issue can be solved by ensuring that the values initially retrieved uniquely define the row (for example, it is the case if a complete primary key is included in the retrieved fields). That is why sqlscreens insists on having an updateindex field list. This will be automaticaly generated from the primary key in some cases, or specified by the application in other cases. There are also other ways, such as using rowids or server-side cursors, but they are database-dependant.

For the second issue, sqlscreens takes the approach to include all the screen's fields in the WHERE clause, not only the updateindex fields. This guarantees that the UPDATE will fail if one of the fields changed in the database. It still might be possible that another field in the record (a field not used by the screen) would have changed since the query, but this change will not be affected by the new update. If this is still undesirable, you just need to include all the appropriate fields in the screen (possibly with the "nodisplay" attribute).


Previous Next Table of Contents