Updated record should come in txt file

For every <b>data element</b>, there is a attribute called <b>Change Document</b>.

For MATNR, this checkbox is ticked. So every time a modification is made, a log is written. Also check transaction <b>SCDO</b>

Regards,

Subramanian V.

Message was edited by: Subramanian Venkateswaran

Hi Parag,

<i>2>. how i can scan log based on time and date.</i>

-> a) example:

SELECT * FROM cdhdr INTO hd

WHERE objectclas = 'DEBI'

AND objectid = kunnr

AND udate IN aedat

AND utime IN utime

AND change_ind = 'U'.

or B) FM CHANGEDOCUMENT_READ

<i>

3>. generation of more log will effect on system performance or not.</i>

-> yes : runtime increases - you must select with

<b>object class and object id</b> !

Grx Andreas

Hi Parag,

To obtain changes you know you can get the details from the tables CDHDR and CDPOS.

Also you have questions about performance and so. SO here are some details.

- When you flag a data element for change document (is checked) it is ONLY a marker that allows for registration of this field's changes into CDHDR and CDPOS. The actual control is done on datafile level in its technical settings (Transaction SE11 with datafile name and then push button "Technical Settings" or CtrlShiftF9). Herein you will find a flag "Log data changes".

Within the CDHDR file and CDPOS file a field OBJECTCLAS is used. Only for existing OBJECTCLAS values the changes are logged.

- Now obvious this is the trick for standard SAP (as Subramanian has already pointed out you can find "OBJECTCLAS" values with transaction SCDO). If you want to know on how to create your own "OBJECTCLAS" values with working logging on your own designed fields follow Subramanian suggestion and read the documentation.

Now to your questions:

You gave some tables you need to track changes (and now also for initial creation) like MARA, MARD, MAKT and others.

To get changes for these tables use the following "OBJECTCLAS" values:

- MATERIAL (Tables MARA, MARC, MARD, MBEW, MFHM, MLGN, MLGT, MPGD, MPOP and MVKE). By-the-way, this object will be replaced by MATERIAL_N (available from release 4.6x).

- VERKBELEG (Tables VBAK, VBAP, VBEP, VBKD, VBLB, VBPA, VBPA2 and VBUK).

To collect changes (suggested by Andreas) you could use function module CHANGEDOCUMENT_READ. This is very usefull if also archiving is active for the objects you need to track changes for and your changes are scattered through time, but for your problem it is better to approach the log data directly.

1. First select the main change documents from CDHDR table for a given "OBJECTCLAS" and "OBJECTID". Here you can use additional filtering on DATE (field UDATE) and TIME (field (UTIME). Even filtering on a specific transaction is possible (field TCODE).

This gives you a number of change documents (field CHANGENR).

2a. Secondly select the specific field changes from table CDPOS by using the found fields from CDHDR and additionally fill TABNAME with the specific table and if required FNAME with the specific field name. 2b. Since in your case the values will not be known, you need to track changes, you have to be very carefull in your selections. If you track the object MATERIAL or MATERIAL_N, you best loop over the MARA table and for each MATNR fill the OBJECTID field of CDHDR with this MATNR value.

3. In order to find NEWLY created items you need to check the CHANGE_IND flag. When 'I' it is an new insert, when 'U' it is an update. Now this rule applies ONLY to key fields, since SAP first creates the key record (CHANGE_IND = 'I') and then the other fields (CHANGE_IND = 'U').

Finally the warning given by Andreas (runtime increases - you MUST select with OBJECTCLAS and OBJECTID) is very important. Not supplying OBJECTID will have a very heavy impact on the runtime.

Hope this gives you some clues on how to approach your problem.

Regards,

Rob.

Another option might be to use ALE change pointers. In the past I have done something very similar to what is described here with this technology. I first create an custom memssage type that is a copy of the standard (matmas becomes ZE_MATMAS). Then you can control what fields in the message type will generate change pointers in transaction BD52. You can activate change pointers system wide in BD61 and per messaage type in the IMG (Basis Components->Application Link Enabling(ALE)->Modelling and Implementing Business Processes->

Master Data Distribution->Activate Change Pointers for Message Types). IMG link is from release 46C.

The standard system will then write the change pointers for you during transaction updates. You can read the change pointers with function module CHANGE_POINTERS_READ. The nice thing about change pointers is that you can mark them as complete after you read them with function module CHANGE_POINTERS_STATUS_WRITE. This way you aren't scanning a huge amount of data at each extraction point. You only are reading the new and updated change pointers.

This is all directly from the technology that SAP uses in their ALE distribution situations.