Most Important Update Statuses
Update management supports different statuses for update requests. These statuses are displayed in
Update Management (transaction sm13) in the column Status.The status indicates the phase of the
update process that the request has reached, or in which the request has become "stuck". The background of the status field can be green (not yet processed, currently being processed), yellow (not yet processed, probably "stuck"), or red (terminated with error). The column Info provides further information.The most important statuses are described below.
As already discussed in the section entitled
The Update Process, the dialog work process passes the update request onto an update work process after the dialog area has been completed. This then processes the V1 update modules. When the ABAP statement COMMIT WORK is received, the data is written to the database and the V2 update is output to a V2 work process (providing V2 modules exist in the update request).The following statuses are possible during this phase:
|
Status |
Phase |
|
initial |
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 carried out. |
|
Error (no retry) |
The update request has been canceled and the update cannot be repeated. |
|
V1 processed |
The init phase has been successfully completed, and the V2 modules are being passed on for further processing. If no V2 modules exist, this update request no longer appears in the overview. |
|
V2 processed |
The V2 modules have also been processed correctly, but there is still a collective run (can be regarded as V3) to be carried out. If there is no collective processing to be carried out, this update request no longer appears in the overview. |
|
processed |
If the parameter rdisp/vb_delete_after_execution is set to 2 - in other words, if automatic deletion is deactivated - an update that has been successfully completed has the status ok. If automatic deletion is activated (default), the update record no longer appears in the overview. |
|
to delete |
This update request has been marked for deletion. |
|
Enqueues deleted |
The SAP locks belonging to this update request were manually deleted (SM12). |
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 anceled the update request. This status can follow on from status prepared. |
An update record may become "stuck" in the status
init without switching to the error status err. If the record remains set to the status init for a prolonged period of time, the record can then be updated in the following ways. The statuses listed below are then active (also see graphic).|
Status |
Phase |
|
Auto(dia) |
The system administrator has manually processed the update record using transaction SM13 (Update requests ® Repeat update).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 the status auto(dia). |
|
Started |
The work process WP2 collects the requests and passes them on in batches to a further update work process (WP3), which then performs the actual update. The record has the status Started up until COMMIT in WP3. |
|
Auto(sys) |
Each time an update server is restarted, the update server checks to determine whether the update requests are set to init. If any update requests are set to init, the update server initiates automatic processing of the requests by means of update work processes.This takes place in the same way as when the update is started manually, except that an update work process (WP4) starts everything and not just a dialog work process. The update record is then set to the status auto(sys). |
This is illustrated in the following graphic:
If, under exceptional circumstances, the update is not successful the first time, the status
Started corresponds to the status initial 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.See also:
Monitoring Updates Analyzing and Correcting Update Errors