Now, I hesitate to post this, just because there is a lot of power in this. But like i learned in Spider-Man, with great power comes great responsibility. And besides, it’s already out there in SCN if you’re looking for it anyway. But I recently ran into an issue where I deleted something I didn’t mean to. it was my dev system, and I knew exactly what I needed to put back. But for some reason it was locked on the screen. I did my diligence to see if I could find a solution, and what I found was surprising… they said edit the table directly and put the info back in there. WHAT?!?
Well, it turns out that in SE16N, if you have debug authorization you can update a table. Rather easily I might add. here’s how:
1) Start ‘se16n’
2) Type ‘/h’ enter debug mode.
Write the variables in debug mode
-> gd-sapedit
-> gd-edit
Change their values ‘X’.
3) Press ‘F8’
it’s that easy. Sure enough, I was able to edit the table, put back the info I needed, and everything started working. This is a great tool for Z tables, but for anything else, I can only recommend the greatest of caution.
Thanks for reading,
Mike
Agree it’s very handy. I have to use it couple of times when user by mistake deleted a routing to which thousands of material variants are assigned….😒😒
Worst kept & most powerful secret. Any Basis / Security Admin that allows debug with the ability to change variables in a production system deserves to be hung out to dry anyway.
Most public auditors like KMPG restrict SE16 for that very reason.
Be warned though CCMS can be configured to generate an alert for each instance where this in invoked, will take a competent auditor/system admin about 10 seconds to have you walked out the door……first time I did it to fix a production issue (on a Z-field extension) the basis admin called me within 30 minutes….