Updating Asynchronously in Steps

When you process a VBLOG entry asynchronously, you can do it in two update steps. This allows you to divide the contents of the update into primary and secondary steps. The primary step is called V1, the secondary step V2. The V1 and V2 steps of a log entry are processed in separate database LUWs. The entries in the lock table are usually deleted once the V1 step has been processed. There is no locking for the V2 step. Dividing up the update process allows you to separate time-critical updates that require database locks from less critical data updates that do not need locks. V2 steps receive lower priority from the dispatcher than V1 steps. This ensures that the time- and lock-critical updates are processed quickly, even when the system is busy.

If an error occurs during the V1 processing, the database rollback applies to all V1 steps in the log entry. The entire entry is replaced in table VBLOG. If an error occurs during V2 processing, all of the V2 steps in the log entry are replaced in table VBLOG, but the V1 updates are not reversed.

The system marks rolled-back function modules as error functions in the update task log. The error can then be corrected and the function restarted later. To access the update task log, choose Tools → Administration → Monitoring → Update. For further information about update administration, see the Managing Updating section of the BC System Services documentation.