Tracking field level changes done to database tables using Se16N

[former_member125661]

Hi experts,

We have let super users/support staff to modify database tables using se16n ( &sap_edit). Now, the auditors are grilling us to find out what fields were modified in these tables. We implement/copied a clone of standard report - RKSE16N_CD to find these entries in tables

SE16N_CD_KEY/SE16N_CD_DATA . But this report only tells us modifications done at record level.

Is there any way we can track changes done to tables via se16n at field level ? I don't think CDHDR/CDPOS tracks changes done using se16n.

Thanks in advance,

Shareen

[former_member125661]

Hi experts,

We have let super users/support staff to modify database tables using se16n ( &sap_edit). Now, the auditors are grilling us to find out what fields were modified in these tables. We implement/copied a clone of standard report - RKSE16N_CD to find these entries in tables

SE16N_CD_KEY/SE16N_CD_DATA . But this report only tells us modifications done at record level.

Is there any way we can track changes done to tables via se16n at field level ? I don't think CDHDR/CDPOS tracks changes done using se16n.

Thanks in advance,

Shareen

[nabheetscn]

Check scu3

Nabheet

[Former Member]

you can go for SCU3 only if logging is activated at system level(or client level),, that means all tables.

more over, dont use SE16n. start developing other applications for this,

because with new patches of SAP, it does not support SE16N

that too, in case of SCU3 usage, in technical setting of tables also you need t o have logging checked for the tables. only those tables are logged.

Edited by: Soumyaprakash Mishra on Jan 11, 2012 9:07 PM

[former_member125661]

Lets say, some fields on a EKPO line are modified. How can I use SCU3 to track which field was modified using se16n ?

I don't think logging is activated at system or client level. Going forward, we will restrict se16n usage with proper documentation. But we are being audited for last yrs se16n changes and we need to know what fields changed in those tables..

Edited by: Shareen Hegde on Jan 11, 2012 4:45 PM

[Former Member]

if you have not activated table logging for your server/client it wont log any table.. irrespective of the log table checkbox in technical setting.

and anyways EKPO does not have the log checked. so it wont.

so for your last years audit.. you dont have trace :)..

you want a hard way to that? then take this.. you have PO outputs triggered when PO is created or changed.. right? check those (if you have archived or stored) with the table data... pfff,i cant imagine how much manual effort will be needed for that.

see, this is the reason SAP is has stopped proving this option.

[former_member125661]

Soumya,

EKPO was just an example I gave..Here we have gone berserk and updated a lot of tables including BSEG,MSEG,etc .It is quite a challenge now to track all fields changed in se16n. Thanks for trying to help.

-Shareen

[Former Member]

sorry to know that mate.. next time dont allow anyone with this SE16N.. cruel tcode.. better upgrade to the SAP patch where they have restricted this...

[Former Member]

I can't understand why there is ever a need to make table level changes in a production system that bypass all application level checks and validations. If you had to do this in production and in your words - having gone berserk - with such changes, you really need to have a look again behind the business need to do such changes.

In my over 10 years experience, there was only a single instance where we had to correct an issue through SE16 debug that arose in a production system due to incorrect configuration that could not be corrected through transport. This we did after full consultation with SAP online support and determining that it is the only way out. Needless to say, after the change we reverted back the authorization

I hope you realize, changes like these mean SOX compliance is thrown out of the window!

This is very bad and I won't blame the auditors doing their duty.

Apply the appropriate SAP patches (note 1420281) that plugin this security hole and completely restrict authority S_DEVELOP objecttype DEBUG activity 03 and 02 and 01, in production systems

**************************************

Now to some good news...

You can still be able to find out which fields are changed along with which table records

Whenever you change a table record using SE16N / &SAP_EDIT, you already know the system will create a record in tables SE16N_CD_KEY and SE16N_CD_DATA. What you should also know is that the system saves the UNCHANGED table record as a long character string (type LCHR) in SE16N_CD_DATA-VALUE field.

If you changed a record 3 times, you will find 3 records in SE16N_CD_KEY and SE16N_CD_DATA-VALUE each storing the record as it was before it was changed.

You can create a ABAP program and implement logic similar to RKSE16N_CD to parse SE16N_CD_KEY-VALUE into structure identical to the db table that is modified. You can do a comparison between these records till the latest record in the db table and generate a diff report. You can use a similar logic as [Comparing Two Internal Tables - A Generic Approach|http://wiki.sdn.sap.com/wiki/display/Snippets/ComparingTwoInternalTables-AGeneric+Approach] by Uwe Schieferstein.

[marcio_ozorio_jesus]

First of all, I would like to thank you for your response.

If the saved records contain the information before it was modified (old), this means that we do not have the information as it was (new), do you agree? We can even make a comparison with later records, however, between one change and another, the information may have been changed in the system and we will not have the exact reference (new).

Do you agree?