Update Statuses
Use
Update management supports different statuses for update requests. These statuses are displayed in update management (transaction SM13) in the Status column.
The status shows the phase of the update process that processing has currently reached. The background of the status field can be green (not yet processed, currently being processed), yellow (not yet processed, probably hanging), or red (canceled with error). The column Info provides further information.
The most important statuses are described below. The dialog work process forwards the update request to an update work process once the dialog part is complete. It then processes the V2 update modules. With the ABAP command COMMIT WORK the data is written to the database, and then the V2 update is forwarded to a V2 work process (provided V2 modules exist in the update request).
In this phase, the following statuses are possible:
|
Status |
Phase |
|---|---|
|
init |
The update request has been created, but has not yet been completely processed. (This status applies from the moment the dialog work process transfers the update request to the update work process to the COMMIT in the update work process). |
|
Error |
An error occurred in the init phase, which prevents the update from being executed. |
|
Error (no retry) |
The update request has been canceled and the update cannot be repeated. |
|
Stopped (no retry) |
The update request had not yet been executed (status initial) when the system was shut down. Since it has the indicator “Cannot be post-updated”, the status was changed to Stopped (no retry) when the system was restarted. It cannot be post-run updated. |
|
V1 processed |
The init phase has been successfully completed, and the V2 modules forwarded. If there is no V2 module, this update request does not appear anymore in the overview. |
|
V2 processed |
If the V2 modules have also been processed correctly, but there is still a Collective Run ( “V3”) to be processed. If there is no collective run, this update request no longer appears in the overview. |
|
processed |
If parameter rdisp/vb_delete_after_execution is set to 2 (automatic deletion is deactivated), an update that has been successfully completed has the status processed. If the automatic deletion is activated (default), the update record does not appear anymore in the overview. |
|
Delete it |
This update request has been marked for deletion. |
|
Enqueues deleted |
The SAP locks belonging to this update request were manually deleted ( SM12). |
Using an External Transaction Monitor
The following statuses are possible if an external transaction monitor is used:
|
Status |
Phase |
|---|---|
|
prepared |
The update request is ready for processing and is waiting for an external transaction monitor to initiate processing. |
|
Canceled |
The external transaction monitor has canceled processing. This status can follow on from status prepared. |
|
Error (ext. Commit) |
The external transaction monitor has started processing, but the SAP system then canceled the update request. This status can follow on from status prepared. |
Status of Hanging Update Records
An update record may become stuck in the status init without switching to the error status err. If the record maintains the status init for a long period of time, there are various options to update the record later. The following statuses are then active (see also the following figure).
|
Status |
Phase |
|---|---|
|
Auto(dia) |
The update record has been processed manually by the system administrator in transaction SM13 ( The dialog work process (WP1) transfers all of these update requests to an update work process (WP2), during which time the update record is set to status Auto(dia). |
|
Started |
Work process WP2 collects the requests and forwards them in portions to an update work process WP3 that makes the actual update. The record has status Started up until COMMIT in WP3. |
|
Auto(sys) |
Each time the update server is restarted, it checks if the status of update requests is init. In this case, it starts processing the request automatically using update work processes. This occurs like a manual start of the update, except that an update work process WP4 starts the entire procedure, and not a dialog work process. The update record is then set to the status auto(sys). |
The following figure displays this situation.
If, under exceptional circumstances, the update is not successful the first time it is processed, the status Started corresponds to the status init when the update is repeated. If the update becomes "stuck" in the status auto or started, the status must be reset, as only records with the status initial can be entered using the methods described.