Z Table change document CDPOS not recording new/old values

[Former Member]

Hello Gurus,

I am updating a z-table (with modify command) and I have followed all of the steps to create change documents.  I am getting the

CDHDR and CDPOS table entries, but the "old" and "new" values are blank.  I am passing a work area that contains the key and the

changed field.  The parameter for "old" values has the key and the "old" value.  The parameter for "new" values has the key and the "new" value.

Everything else has been followed by the book (ie SCDO document create, data element changes, etc...)  What am I missing ?  Thanks !

[Former Member]

Hello Gurus,

I am updating a z-table (with modify command) and I have followed all of the steps to create change documents.  I am getting the

CDHDR and CDPOS table entries, but the "old" and "new" values are blank.  I am passing a work area that contains the key and the

changed field.  The parameter for "old" values has the key and the "old" value.  The parameter for "new" values has the key and the "new" value.

Everything else has been followed by the book (ie SCDO document create, data element changes, etc...)  What am I missing ?  Thanks !

[Former Member]

Hi

You should post how you call the fm updates CDHDR and CDPOS

Max

[Ruediger_Plantiko]

Michael,

What am I missing?

Which function module are you calling? <...>_WRITE_DOCUMENT ? Usually, the function module is called in the V2 update step, during COMMIT WORK, but it is possible to call it in other contexts, too.

Since you have CDPOS and CDHR entries, I suppose it's not the COMMIT WORK missing.

Can you isolate the problem and boil it down to a very small test report?

Regards,

Rüdiger

BTW: Try to avoid the database statement MODIFY. It's twice as expensive as UPDATE. Normally, you know in a transaction which entries are new and which are old ones that have to be updated (by keeping track of the changes with an update indicator or similar mechanisms).

[Former Member]

Here is the function module being called and the parameters.

CALL FUNCTION 'Z_SD_MAINT_AVAI_WRITE_DOCUMENT'

EXPORTING

OBJECTID = '13000000000000000013120120511'

TCODE = SY-TCODE

UTIME = SY-UZEIT

UDATE = SY-DATUM

USERNAME = SY-UNAME

PLANNED_CHANGE_NUMBER = ' '

OBJECT_CHANGE_INDICATOR = 'U'

PLANNED_OR_REAL_CHANGES = ' '

* NO_CHANGE_POINTERS = ' '

UPD_ICDTXT_Z_SD_MAINT_AVAI = 'U'

O_ZDT_AVAIL = gs_old_final "old values

N_ZDT_AVAIL = gs_final "new values

　

UPD_ZDT_AVAIL = 'U'

* LV_OPT = ' '

TABLES

ICDTXT_Z_SD_MAINT_AVAI = T_CDTXT.

COMMIT WORK.

[Former Member]

Hi

I suppose 13000000000000000013120120511 is the right key of the record you need to change, isnt' it?

Then you need to considere the change document elaborates the changing of he fields of your Z-table linked to data element with flag for CHANGE DOCUMENT set

Max

[Former Member]

Thanks Max.....Yes, that is the right key.....There is one more field (which is the one I am changing).....Yes, I have the data element marked for "Log Changes"....so, the work area for "old" is 13000000000000000013120120511N and the work area for "new" is 13000000000000000013120120511Y.  I am changing the field from "N" to "Y".   Thanks, Mike

[Former Member]

Hi

You don't call the fm in UPDATE TASK so I believe you don't need to use COMMIT statament, anyway a routine calling your fm should be created when you have generated your object in SCDO

Have you tried to check it?

Max

[Former Member]

Hi Max....Yes, I have tested the FM in SE37 and still cannot get the old and new values to display.

Thanks,

Mike

[Former Member]

Hi

Try to regenerate your object by SCDO

Max

[Former Member]

Hi Max

I have re-generated the object in SCDO.  I have re-tested the FM in SE37 and still does not display the old and new values.  I'm wondering if I should delete the object and try to re-build it from scratch.

Thanks,

Mike

[Ruediger_Plantiko]

Hi Mike,

did you ever try to debug the function module? It's automatically generated, I know, but you wan't get a trauma when debugging it - it's still readable. Debugging is a thing which you would have to do on your own. It is no worth to discuss the single steps in the forum, no expert can give you the answer of a debugging session. If I were in your position, I would do it.

Another thing: Did you compare your call with the call of one of the standard modules, for example VERKBELEG_WRITE_DOCUMENT in module pool SAPMV45A. This is the call for the change documents of a sales order.

Regards,

Rüdiger

[Former Member]

Hi

I've created several times custom objects for change document and no problem occurred, so iif you think all steps for generation were ok, yes....you should try to create it again,

Max

[Former Member]

Hi Rudiger,

Thanks for the input.  I have tried debugging the FM, but I tend to get lost in the routine for "Single Case"...It tends to call several functions....I may try it again though....I will try your second suggestion to compare with VERKBELEG_WRITE_DOCUMENT....Thanks, Mike

[Former Member]

Hi,

Do the ObjectID fields (1 for the FM and 1 for ICDTXT) have to be the specific row key ?  It seems like some documentation says you must provide the key and others seem to indicate you could put anything in there...........Also, when I specify the "Old" and "New" values do I need to provide all fields of the row or just the "Old" and "New" values ?  Thanks....Mike

[Former Member]

Hi

I've never transfered any value in CDTXT, both records (old and new) should be fully filled.

Max

[Ruediger_Plantiko]

Mike,

 but I tend to get lost in the routine for "Single Case"...It tends to call several functions....I may try it again though....

When you reach the ...SINGLE_CASE, the following parameters have to be filled correctly:

• CHANGE_INDICATOR = 'D'/'I'/'U' for Delete, Insert, Update case.
• TABLENAME: The name of your database table
• WORKAREA_OLD: A structure with the type = your database table, containing the data before the user has changed them in the current transaction. Or initial, in the insert case.
• WORKAREA_NEW: A structure with the type = your database table, containing the data as the user has changed them in the current transaction, before he had hit "save".
• DOCU_DELETE = SPACE, if you only want one change document for the deletion of the complete entry (which is the usual case).

When you come to ...SINGLE_CASE in the debugger: Are the fields filled in this way, in the expected way?

Also, when I specify the "Old" and "New" values do I need to provide all fields of the row or just the "Old" and "New" values ?

You always pass the complete structure, as it is/was after/before the user's change, as explained above.

Regards,

Rüdiger

[Ruediger_Plantiko]

Mike,

 but I tend to get lost in the routine for "Single Case"...It tends to call several functions....I may try it again though....

When you reach the ...SINGLE_CASE, the following parameters have to be filled correctly:

• CHANGE_INDICATOR = 'D'/'I'/'U' for Delete, Insert, Update case.
• TABLENAME: The name of your database table
• WORKAREA_OLD: A structure with the type = your database table, containing the data before the user has changed them in the current transaction. Or initial, in the insert case.
• WORKAREA_NEW: A structure with the type = your database table, containing the data as the user has changed them in the current transaction, before he had hit "save".
• DOCU_DELETE = SPACE, if you only want one change document for the deletion of the complete entry (which is the usual case).

When you come to ...SINGLE_CASE in the debugger: Are the fields filled in this way, in the expected way?

Also, when I specify the "Old" and "New" values do I need to provide all fields of the row or just the "Old" and "New" values ?

You always pass the complete structure, as it is/was after/before the user's change, as explained above.

Regards,

Rüdiger

[Former Member]

Thanks Rudiger.....I will try the debugging again......Also, I noticed that after I test the FM using SE37 and run program RSSCD200 that the Table Name (in report RSSCD200) is always the name of the document change object and not the name of the specific Z-table.......Thanks, Mike

[Former Member]

Rudiger.....I went back to debug the FM module again after your suggestion.....and....I found the problem !!  I had changed the data element (the one for logging changes) to accept changes (in further characteristics), but did not ACTIVATE the element.  I noticed it was inactive and as soon as i activated it, then the FM started working properly !!!......Thanks for your help....much appreciated !!

Max....Thanks for your input as well !!

Mike