Basic Question about Maintenance Dialog

[Former Member]

Say I have an application database table in SAP that I want to allow perhaps one trusted user to directly edit, but only with auditing. However, I only want auditing to occur when it is edited by a person, not a batch process.

Are maintenance dialogs on the database table what I want? Or should I be looking at something else?

Thanks for any replies.

[Former Member]

May be you can create a table maintainence to that table and give authorizations only for that user so that only that person will able edit it. And regarding batch process you can put a check like below in the Event -> initialization

If sy-batch = 'X'.

exit.

endif.

Enjoy,

Satya

[RichHeilman]

"Auditing" being validation checks? Yes, you can use maintenance dialogs for this, you use the table maintenance generator to create the dialog program. There will be not validation checks at this point. You have to manually add them. There are a couple of posts in this forum about how to do that.

Regards,

Rich Heilman

[Former Member]

Hi Rich. By auditing, I meant really capturing changes that are made, since under extraordinary circumstance we want to allow the table to be changed, but only if we can audit the changes, and only if that audit doesn't occur during a batch load, thereby slowing it down.

Thanks for any brain cycles you could spare.

[RichHeilman]

Oh ok. I know that you can turn on "logging of changes" in SE11, under the technical settings. Here is the help on this flag.

<i>Log data changes

The logging flag defines whether changes to the data records of a table should be logged. If logging is activated, every change (with UPDATE, DELETE) to an existing data record by a user or an application program is recorded in a log table in the database.

Note: Activating logging slows down accesses that change the table. First of all, a record must be written in the log table for each change. Secondly, many users access this log table in parallel. This could cause lock situations even though the users are working with different application tables.

Dependencies

Logging only takes place if parameter rec/client in the system profile is set correctly. Setting the flag on its own does not cause the table changes to be logged.

The existing logs can be displayed with Transaction Table history (SCU3).</i>

Now, once this is put on, I don't know if you can choose when the changes are logged by a certain condition, in this case, when SY-BATCH = 'X' or not. I think that its all or nothing. Otherwise whats the point, right?

A work around..... and it will be work. You can write your own table maintenance program which the user will use to update the custom table. In this program you will need to have your own little "change log" routine, which will write to another custom table. Now you are logging changes for the user interface, if you have something else updating this file in background, then you simple update since the "log changes" checkbox is not checked.

Make sense?

Regard,

RIch Heilman

[Former Member]

See if events work for you. Here is one event that is of particular interest.

Event AB 

Execution : Instead of the standard database changes routine

Use

This event occurs at the 'Save' function. A different logic from the standard can run, for example to also change hidden tables in the database.

Realization

The following standard routines can be used or be a template for the realization of the user routine:

· Maintenance dialog based on a view:

routine FORM DB_UPD_<view name>

· Maintenance dialog based on a table:

routine FORM TABLE_DB_UPD.

If entries are deleted, they must also be deleted in the internal table EXTRACT, and the flags be reset. (See the standard routine logic).

The following global data is available:

internal table TOTAL 
field symbols <ACTION> and <ACTION_TEXT>

You can access events in transaction SE54, in the menu, "Environment-->Events".

[Former Member]

<i>A work around..... and it will be work. You can write your own table maintenance program which the user will use to update the custom table. In this program you will need to have your own little "change log" routine, which will write to another custom table. Now you are logging changes for the user interface, if you have something else updating this file in background, then you simple update since the "log changes" checkbox is not checked.</i>

Sounds like exactly what I had in mind, but I wasn't sure if code to insert to a custom table could be triggered from a maintenance dialog. Sounds like it can. Thanks.

[RichHeilman]

That would be another option. Create the table maintenance program using the generator and then hack it to write a custom change log when the user uses the table maintenance program via SM30.

Good thinking!!

Regards,

Rich Heilman