Debug ST22 dump called with IN UPDATE TASK

[vincent8]

I have a DBSQL_DUPLICATE_KEY_ERROR in our production system that's occuring in FM ADDR_SAVE_INTERN (Line 720 on procedure 'write_to_db' on table adr2). I cannot reproduce the issue either, but it happens a couple times a day in our production system, seemingly at random. The problem I have is I want to see the call stack, but since it's in called IN UPDATE TASK, I don't know where it's being called from.

Is there a way from ST22 (or other) to see what is the calling point of this UPDATE TASK FM?

Thank you,

Vincent

[Gourab_Dey]

There must be an issue with standards. Debugging will not help bcoz it seems the issue is with Central address maintenance. It can be from BP or PO or something else which we don't know. Try to find out snote for the issue else, raise a issue to SAP. I found the below note which is relevant for same issue while BP Creation. Check if it helps.

https://launchpad.support.sap.com/#/notes/2943343

Also check out the "Chosen variable" section of the dump, you may find any clue, something like a Name and something which you can check with the user whether they have created any new BP or PO.

Thanks,

Gourab

[vincent8]

Thanks for the reply Gourab. It might also be custom code as we have a custom FM calling ADDR_SAVE_INTERN in update task. The note you provided cannot be implemented in our system (already implemented). I would really need to know the calling point, so I can debug and from that I would know the business process and possibly reproduce the issue.

[Gourab_Dey]

Ok. Gotcha.

Did you tried checking SM13 to check if there is any failed update? If an update is failed, then generally it logged in SM13.

Thanks,

Gourab

[vincent8]

Yes, there is an entry in SM13, but I can't seem to gather more information from this than ST22.

[Sandra_Rossi]

Check SAP notes or contact SAP support.

[vincent8]

Obviously I checked the notes. Before contacting support, I would have liked to investigate and make sure the issue isn't within our custom code.

[Gourab_Dey]

I tried checking in my system. I am able to see the report program and the t-code for the same. Please check the header data of the failed request. It should give you those details.

T-Code: SM13

Header data with Report and t-code:

Debugging option: It might help, not sure though

Thanks,

Gourab

[vincent8]

As you can see, the header isn't very helpful here. And I am a bit wary of re-running the FM in prod directly... I cannot reproduce this behavior in any other system

[matt]

vincent8

The function module is ADDR_SAVE_INTERN but I guess that doesn't help much.

I think you'll have to go to ST05, and start an RFC trace on all app servers. Possibly an HTTP trace.

[matt]

Don't post comments as answers. As it says:

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.

[matt]

From SM13, you can rerun the FM and debug it. Looking at the header tells you the report and transaction that was running.

Btw - don't post comments as answers. As it says:

[vincent8]

Yes I misclicked, sorry.

As you can see, the header isn't very helpful here. And I am a bit wary of re-running the FM in prod directly... I cannot reproduce this behavior in any other system

[FredericGirod]

As matthew.billingham said, you should do a ST05 trace, and check all the update you are trying to process.

There is a Duplicate_Key .. meaning you are trying to insert a row with an already existing key. It could be a Range number error (could be a big mistake by the functional team : you could check in table e071 in dev system if someone have inserted a TNRO table lines in a transport request).