Skip to Content
Why you should not do this in any productive system, or any system that you don’t wish to restore because you’ve messed up referential integrity….

  • Reason 1: If you are ISO certified, then you will be going against their instructions
  • Reason 2: If you are bound by SOX compliance then you will not be adhering to it
  • Reason 3: You can cause data inconsistencies between tables that have relationships with each other. It will not maintain referential integrity between the tables.
  • Reason 4: SAP will not support any inconsistencies brought about by this method

Regarding security around this feature here are some points to note:

  1. It can be protected by the developer authorization S_DEVELOP (object type DEBUG activity 03 and 02 and 01). The user needs access to both SE16N and DEBUG before it’s available.
  2. All changes to table contents are updated in seperate change document tables. These tables are:
    – SE16N_CD_KEY : Change Documents Header – Stores the user, the modification date and time
    – SE16N_CD_DATA : Change Documents Data
  3. In addition you can apply notes 503274 and 597117 to specify a display transaction only, which does not allow table changes.
  4. If you are paranoid then block the transaction via SM01
  5. If you are crazy paranoid then remove the transaction from table TSTC 😉

Lastly a comment from Julius:
“For other readers, please also see SAP note 587410. With this authorization, you can use SE16N’s function modules to go *accross client boundaries* and turn the change authorization checks on S_DEVELOP and S_TABU_DIS OFF (!) when calling the FM.”

Suggestions for use:

I only use this on Z tables in a development environment where I do not wish to have table maintenance generated and I understand the referential integrity associated with the table.

Any thoughts and comments go to TIP: Changing entries directly in any SAP table

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Andrea Olivieri
    Hello Kewin,

    If you search for SAP notes with the keyword SE16N and primary component CO-OM, it seems that this transaction and the authorizations implications are well documented.

    However in my opinion, in your blog you missed that the SE16N transaction was designed to update only the customizing or system tables which cannot be updated through IMG or SM30 (without maintenance dialogue).

    (0) 
  2. Julius von dem Bussche
    “turn the change authorization checks on S_DEVELOP and S_TABU_DIS OFF (!) when calling the FM.”
    This is only possible in the dynpro. If you try to save, then all three (01, 02, 03 debug) checks are performed.

    However if you can call or single test FM’s at will, then these checks are not an obstable.

    Cheers,
    Julius

    (0) 
  3. Peter Jæger
    Hi Kevin

    Very interesting topic!

    Please be aware that you now can deactivate &SAP_EDIT by implementing Note 1420281.

    PS: would it be possible to add this blog to the category Security ?

    Cheers,
    Peter

    (0) 
    1. Julius von dem Bussche
      But if the user is still authorized to make changes in the ABAP debugger, then this only makes the changes less user friendly…

      They can still create their own program and submit it!

      Cheers,
      Julius

      (0) 

Leave a Reply