2006 Aug 25 11:56 AM
2006 Aug 28 6:29 PM
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.
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.
2006 Aug 25 12:07 PM
If you want to see the changes of the "System change options settings" I propose to goto transation SE06 -> 'System Change Option' -> 'Log'
2006 Aug 26 3:42 AM
Thank u for ur reply.
Am looking for SCC4 logs. Thanks for ur kind advise.
2006 Aug 26 8:17 PM
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).
2006 Aug 25 12:23 PM
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'
2006 Aug 25 1:14 PM
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.
2006 Aug 26 3:40 AM
Hi ruchit,
Thanks for ur immediate reply.After I chose Utilitis>Change logs and gave the date rangeExecute, 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?
2006 Aug 28 6:29 PM
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.
2006 Aug 28 9:39 PM
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?).
2006 Aug 29 12:01 PM
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
| User | Count |
|---|---|
| 3 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |