Quick rule of thumb for SM13?

[Former Member]

Generally, I assume that SM13 entries just need to be deleted because they are always associated to an UPDATE TERMINATION and reprocessing them would only cause trouble because their originating transaction never actually committed. But recently, somebody challenged me with this assumption and asked around about this. Only to find out that they are a lot of different opinions floating around(including in SDN) on the subject.

Does somebody have a simple rule that would explain what to do with those SM13 entries?

Thank you!

[tim_buchholz]

Dear Patrick,

this stems from the fact that there are different types of update modules! There are so called

V1 update modules. These normally come with an enqueue (SAP lock) being set to ensure

that data is altered in a controlled way. If the update fails, the enqueues will be released. As

you can imagine, this means that the update can not be redone - and actually SM13 will not

let you redo the udpate request anyway.

There are also synchronous updates (indicated by two squares with an arc above them). If

a synchronous update fails, the caller will be notified, and it is up to the caller to do a proper

error handling.

The there are V2 updates. These come WITHOUT enqueues. By definition, a V2 update can

ALWAYS be redone. That is, an update request which only has V2 function modules. In

this case, you will have to figure why the update failed (e.g. because there was a database

error, or an error in the application side), fix this problem, and then redo the update request.

Finally, there is V3 (collective run). This is similar to V2, and comes with no enqueues. Same

as V2 applies.

Generally, you can not harm your system when you attempt to redo an errorneous update

request from SM13, as the update control will check if the request can be redone at all. If

it can not, you will probably have to redo the activity that created the update request on

application level.

Please also check the documentation, and the notes 70085, and 552300.

Best Regards,

Tim

[Former Member]

Patrick,

I would take following steps.

1. Check SM13 (as you already did).

2. Note down date/time and originator (user).

3. Check SM21 and ST22 ( you may find the answer here like some oracle error number etc)

4. Consult with originator or functional consultant.

Hope this helps.

Manoj Chintawar

[Former Member]

Hell Patrick,

There is nothing so called simple in this world,isnt'it!!!!

well I agree that update errors should not be reprocessed neither they should be deleted.A proper anaysis needs to be done by your functional team why has the update error came.

If you observer a single update error,you can ignore that but suppose if you find multiple update errrors,it has to be looked upon.

You can just double click on the update error and ask your functional team to analyze what went wrong and where.sometimes you can also find that updates failing due to system issues and not functional problems which again need to be anaylzed

I hope this helps you,let me know of any questions

Rohit

[Former Member]

HI Patrick

Firstly on SM13

About SM13 transaction code:

SM13 (generally) is Update management tcode.

SM13 used for checking terminated update records on our manual check.

Basically Update management is used for the following:

Display update requests.

Analyze problems pertaining to the update.

Test and debug canceled update requests.

Display and reset the status of update requests.

Delete update requests.

Display statistics on updates.

SM13 transaction code is basically used to monitor the update statistics. In this tcode we can find out if any uncommitted updates are there for a particular user. We can check critical updates and non critical updates here. And also we can specify the date and time when there is an update error happened in our system. In netweaver system, Shift +F5 will lead us to the administration of the update system.

Secondly, about the entries, I dont think the only thumb rule that may exist as far as my knowledge goes is to report the failure.

and report it with details like the report that caused the failure, time and user, exception , and the error details

The following analogy should help clarify this concept:

1. A secretary gives a file clerk a folder (similar to a save).

2. The file clerk gives the secretary a receipt (similar to the R/3 document number).

3. On the way to the file cabinet, the clerk falls, and gets hurt.

The folder in not put into the cabinet (this is the failed update).

4. The end result is the folder is not in the cabinetu2014even though the secretary has the receipt

I hope this helps

Regards

Chen