Each SAP transaction is considered as Single LUW (Logical unit of work) which in turn contains multiple LUW's needs to be committed to commit the SAP Transaction. If any one of the LUW is failed the entire transaction is rolled back. That is the reason why dialogue updates Temp Table.
1. User submits the request.
2. Dialogue handles the request.
3. Obtains lock from Enqueue so the data consistency is achieved and the records are only for display.
4. Updates the request in Temp tables (VBHDR, VBDATA, VBMOD, VBERROR)
5. Gets the transaction ID from NRIV (Number Range Interval Table)
6. Update gets initiated to update the VB* content permanently into the database.
7. Update inherits the locks.
8. Updates the database based on transaction ID.
9. Update releases the lock from the record.
The following are the statuses displayed in SM13 Transaction.
INIT The record is waiting to update by an update process.
ERR The record runs in to an Error (Update Error)
RUN The update is executing the record into DB
AUTO The error records are reprocessed after a system restart/ update activation
SM13 - Repeat Update
Used to repeat the ERR updates. The update are terminated or cancelled due to the following reasons
1. Table space overflow
2. Max Extents reached
3. Archive struck
4. Programmatical Error
5. Update Deactivation (SM14)
Running updates during deactivation
Deactivate -----------> Throws to Error -------------> Goes to Auto
At this point of time we need to select the update (put a check mark of the update from SM13) and click on [Repeat Update]
Refer modules from SM13
The updates can be repeated with status ERR
Rdisp/vbmail = 1 to send email to the users if an update is failed.
Update mechanism can be deactivated by setting the parameter
rdisp/vb_stop_active=0 to deactivate the update mechanism in case of DB errors.
It can be activated from SM14.
rdisp/vbdelete=30 to delete the update records older than 30 days irrespective of the status.
Rdisp/vbreorg =1 to delete the incomplete update request during a system restart.