It’s an open secret: anyone looking for what holds SAP together at its core inevitably ends up in the database. Due to the consistently cross-platform application design, this is the architecture chosen for SAP. Therefore, it is extremely exciting for experienced SAP users to gain access to these very tables. Here is what options are available.
Foreword
„Knowledge is power“ says the popular saying, and it is often no less important to mention that knowledge is also responsibility. SAP tables are interconnected in numerous complex relations. It is not for nothing that changes to these contents are encapsulated in FuMos and reports that are aware of these dependencies. In some cases, the conditions also change with a release upgrade or support packages.
In short : who changes tables, should know exactly what he does. In the worst case he will destroy the system completely and permanently. The ways mentioned here are by no means illegal or „against the product specifics“. SAP itself offers these ways for authorized persons in the form of „intended functionality“, not everyone knows them.
In addition, special attention must be paid to audit-relevant content. Changes in tables are not logged and therefore aren’t traceable. Therefore, in the production system, stay away from application tables that contain header or document data, as you could annoy the auditor in the long run. Keeping this in mind can’t hurt when you enter the shallows of direct table changes.
Just playing…
Certain activities require regular adjustments to tables even in non-changeable systems. For example, if you want to maintain currency rates and (!) your client is marked as „productive“, you can configure these special table maintenance options using transaction „SOBJ“. Note 135028 is then your friend, among others.
The hard way (I may use SE16N)
A „nasty“ way (because not provided outside of development environments) is to set the OK code „&SAP_EDIT“ in SE16N (alternatively : Debug -> GD-EDIT = X). Of course this only works if your authorization administrators allow the SE16N. This way you can persuade many – otherwise stubborn – tables to cooperate.
Note: SAP has partially changed the functionality here (sometime in 6.40). However, the resourceful administrator can restore the old behavior at his own risk with some hints : 1446530 ; 1468636 (only internally released, but still installable) ; 1525586.
The hard way (part 2)
If you are allowed to debug, you are allowed to do everything. That’s why a lot of emphasis is put on this authorization in the authorization concept. With the „/h“ (OK code) authorization, writing can be activated without problems in the SE16 even in read mode, or the „obsolete“ message can be bypassed in the UASE16N.
Into the write mode: Set „sy-ucomm“ to „EDIT“ („DELE“, „INSR“), and the corresponding table is open for all experiments.
The stubborn way
While the ways shown so far require very wide rights, a program in the minimal version can also grant ‚only‘ SA38/SE38 owners access to table changes. Again, be careful especially in production. This is completely unsuitable for end-user use, here appropriate checks would have to be added if SA38 is widespread in your company. The following source code actually calls only one function module, but it has not been tested by me yet:
REPORT ZZBC_TAB_SELECT.
parameters: z_tab type se16n_tab obligatory,
z_anz type sytabix DEFAULT ‚1000‘.
START-OF-SELECTION.
CALL FUNCTION ‚SE16N_INTERFACE‘.
EXPORTING
I_TAB = z_tab
I_EDIT = ‚X
I_SAPEDIT = ‚X‘
I_MAX_LINES = z_anz.
The direct way
The database administrator still has it best. Every database offers tools and interfaces to customize table contents (Oracle sqlplus via OPS$, MaxDB Database Manager via XUSER), and these can be used for many practical things with enough expertise.
Here are some key words :
- the SAP* user is located in table USR02 and is assigned to a client by MANDT
- the RFC destinations can be fetched from RFCDES before overwriting the system (please do not forget: RFCATTRIB, RFCCMC, RFCDOC, RFCSYSACL, RFCTRUST)
- … or invalidate class after system copy („.. set rfcoptions = replace (rfcoptions,’H=‘,’H=#‘) where rfctype = ‚3‘; … = ‚T‘;)
- the batch jobs should be scheduled according to the system copy guide (TBTCO status P and TBTCS)
The mandatory
This documentation is a collection of empirical values, and has not been tested or released in any form by the product manufacturers (SAP, Oracle, ..). No liability can be assumed for damages resulting from (partial or complete) following of this documentation.
Of course I am happy about questions, comments or additions.
