topic Re: SCC4 Logs in Application Development and Automation Discussions

SCC4 Logs

Former Member — Fri, 25 Aug 2006 10:56:39 GMT

How do we get logs for who has changed the settings in SCC4?

Re: SCC4 Logs

Former Member — Fri, 25 Aug 2006 11:07:03 GMT

If you want to see the changes of the "System change options settings" I propose to goto transation SE06 -> 'System Change Option' -> 'Log'

Re: SCC4 Logs

Former Member — Fri, 25 Aug 2006 11:23:37 GMT

you can also goto transaction SPRO -> Tools -> IMG Logging -> Analyze logs (alternativly goto SE38 and enter report RSVTPORT) enter T000 and select Tables and choose the correct 'From' and 'To Date'

Re: SCC4 Logs

Former Member — Fri, 25 Aug 2006 12:14:12 GMT

Hi Prasad,

it is simple. In SCC4 after you have chosen the client go to UTILITIES in menu bar and choose change logs. It takes you automatically to report RSVTPROT with the name of the table automatically filled. Just give the date range for which you want to view change logs and execute it. If you try RSVTPROT through SE38 then you need to supply table name. So I thing this approach is the best.

Please award points if this solved the issue.

Regards.

Ruchit.

Re: SCC4 Logs

Former Member — Sat, 26 Aug 2006 02:40:50 GMT

Hi ruchit,

Thanks for ur immediate reply.After I chose Utilitis~~>Change logs and gave the date range~~Execute, am getting the result showing "No logs found for the selected period" ( Actually I have given the date range as from 2003, but still showing the same result,& am aware that we have changed the settings few number of times from 2003).

Note : I chose Logging:Display status, It shows Logging is switched off. I guess this may be the cause. How can we switch it on?

Re: SCC4 Logs

Former Member — Sat, 26 Aug 2006 02:42:28 GMT

Thank u for ur reply.

Am looking for SCC4 logs. Thanks for ur kind advise.

Re: SCC4 Logs

Former Member — Sat, 26 Aug 2006 19:17:24 GMT

SCC4 (or other methods of the same order) will only have the table change logging activated for changes (i.e. generic SCU3 information), after changing the system param rec/client = ALL (clients). The default = OFF (clients). You can call SCC4 from any client...

There is an old SAP note which explains this nicely. Also see the SAP notes on the transport profile "recclient".

This logging will make the table change logs available for changes to ALL tables (not just T000) if they are flagged for logging of this type (in SE11 -> <table name> -> Technical properties -> Change logging flag is set) and the change is made using a SAP standard table maintenance view or the system transaction designed to make the change (i.e. SM30, SCC4, STMS etc etc).

Also search this forum for "What is wrong with SE16?".

Take note that if you change T000 technical settings and then change T000, then there might not (necesarily) be a log (default installation).

Re: SCC4 Logs

Former Member — Mon, 28 Aug 2006 17:29:08 GMT

Hi Prasad,

Just check in RZ11 the value of system profile paramter :

"rec/client" in your system. I suppose the value would be off.The client(s) where you want table logging to be active should be mnetioned in this profile parameter.

Once you activate it then you will be able to check SCC4 logs in future.

I am sorry I think the old logs won't be available since they were not recorded.

Regards.

Ruchit.

Re: SCC4 Logs

Former Member — Mon, 28 Aug 2006 20:39:03 GMT

If the question relates to a specific incident, then you can get most of the information back for a limited period of time if you must, even if the logs are off.

On the other hand, even if the logs are turned on (all of them), then you will not be able to log all changes if the user has something stronger than just SCC4.

It is a chicken-or-the-egg first situation: Do you write the log before the work is commited (and have the risk that the commit fails?). Or do you commit the work and then write the new : old value to the log (and have the risk that an abrupt exit occurs before the log is recorded?).

Re: SCC4 Logs

Wolfgang_Janzen — Tue, 29 Aug 2006 11:01:11 GMT

The "chicken-or-the-egg first problem" is resolved by writting change records to the database with the same commit that also persists the actual changes. So, that's just using the transaction concept provided by the DBMS.

Regards, Wolfgang