Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

update eban anymously

Former Member
0 Likes
682

hi all,

we are having this mysterious problem, that somehow our PRs got updated with the same requestor's name(TTCHAN) up to more than 100,000 data , i have checked my user exit, programs and i cannot find in any way that how the updates goes on. Somehow there was no history track of the update.

can anybody pls give idea where and how i can track the root cause.. or is it possible that system holds buffer memory of TTCHAN .. pls advice

1 ACCEPTED SOLUTION
Read only

Former Member
0 Likes
638

Hi,

This is really mysterious!!!

Probably, if logging is activated in your server, you can check the CDHDR and CDPOS tables for old and new entries for EBAN table. I guess the transaction that updates these are ME52. Hence, you can search the table via this transaction code.

And, just search, if someone has attatched an event assosciated with this table, where he has hard-coded TTCHAN as the approvers name. Goto SE54, type in the table name (EBAN) and check for the events. It's highly improbable, but defenitely worth a try.

Regards

Anil Madhavan

hi all,

we are having this mysterious problem, that somehow our PRs got updated with the same requestor's name(TTCHAN) up to more than 100,000 data , i have checked my user exit, programs and i cannot find in any way that how the updates goes on. Somehow there was no history track of the update.

can anybody pls give idea where and how i can track the root cause.. or is it possible that system holds buffer memory of TTCHAN .. pls advice

3 REPLIES 3
Read only

Former Member
0 Likes
639

Hi,

This is really mysterious!!!

Probably, if logging is activated in your server, you can check the CDHDR and CDPOS tables for old and new entries for EBAN table. I guess the transaction that updates these are ME52. Hence, you can search the table via this transaction code.

And, just search, if someone has attatched an event assosciated with this table, where he has hard-coded TTCHAN as the approvers name. Goto SE54, type in the table name (EBAN) and check for the events. It's highly improbable, but defenitely worth a try.

Regards

Anil Madhavan

Read only

0 Likes
638

HI Anil,

Thanks alot for replying. Yes i have checked history table since the mysterious update happened, only 5 PRs got history updated via ME52N, the rest 100,000 PRs still no history of how it can be updated.

I have checked me54 for event, but it is empty.

anyways, we are still checking on how the root cause can happend

Read only

0 Likes
638

Hi Ester,

It's bad that the solutions didn't work out. If you can create a test PR (in a production system, I know its going to be tough) after activating the SQL trace using ST05, you can analyse if the real values or TTCHAN is going into the table. We can then confirm if the PR is getting updated right during creation or at a later stage.

Regards

Anil Madhavan