SAP Library - Find your answers

SCU3 transaction is used to see the IMG change logs for modified objects.

If your table change log is not active, it will gives you a message that :-
...table logging is switched off...

This particular setting can be changed in the following path :-
IMG--> Basis Components --> System Administration --> Tables changes recording

You can log changes made to the following tables:

- Control tables (system logic control)
- Customizing tables
What is recorded is always in the form of complete "before" images, that is, all entries as they appear before the changes.
The recorded data is compressed without buffering, and this is not an appropriate method for recording and managing large amounts of data. Activating logging impacts on performance as it entails twice as many database updates as would otherwise be the case, and the database storage load is also increased substantially.

It is recommend that you use logging for your production clients and Customizing clients so that you can see exactly where Customizing tables have been changed. Other than the reasons above, it is not recommended that you use this tool for application tables.

Two conditions have to be met for a table to be logged:

1. The table has to be selected for logging in the Dictionary (see Dictionary -> Table maintenance -> Technical configuration).

2. Logging also has to be set in the system profile
Set the rec/client (note the use of lowercase characters) profile parameter to one of the following values :-
- OFF: no logging at all (effectively a central system switch)
- nnn: logs client-specific tables in client nnn only
- mmm,nnn,ppp,...: logs client-specific tables in the named clients
- ALL: logs all client-specific tables in all clients.

Caution: Only in exceptional circumstances is it appropriate to use the 'ALL' setting. If, for example, the profile parameter is set to 'ALL' when you upgrade all test clients (including 000, the SAP client), these changes are recorded in the system log file. This reduces performance and requires a lot of database space.

The default setting is OFF (no changes are logged).

If logging is set in the ABAP Dictionary, changes to client-indepedent tables are always logged unless rec/client is set to 'OFF'

Use the ABAP programs RSTBHIST or RSVTPROT to analyze table changes. RSVTPROT allows you to analyze change logs both at table level and with reference to Customizing objects. To access the program, select an executable Customizing activity in IMG and choose Goto -> Change log.

Syntax error in SDCC, table inconsistency between ABAP Dictionary and the database, transport error 8 during the generation of ABAP Dictionary. When you call Transaction SDCC, a termination occurs due to a putative syntax error because a table is not known or active. When you check this with the ABAP dictionary (SE11), you notice, that the table is active or inactive, however it is not possible to activate it. The activation might terminate with the error message 'Inconsistency between ABAP Dictionary and database'. A check of the affected object also delivers this error.


Proceed as follows:

Log on as user DDIC
Call Transaction SE14
Enter the affected table name and
select EDIT
In the following screen, choose Table -> Reconstruct
Confirm the execution
Call Transaction SE11
Enter the affected table name
Display
Activate
If - after you chose EDIT -, the error message occurs that the table only exists on the database, you need to activate the source and the runtime object.

Call Transaction SE37:
-> Function module 'DD_TABL_ACTM' -> Single test
Under import parameter MODE, enter the number 12 and under TABNAME the corresponding table name
-> Execute (F8) -> Export parameter ACT_RESULT must be 0
Call Transaction SE14 again as described above.
-> Extras -> Database object -> Check,
as well as
-> Extras -> Runtime object -> Check
inconsistencies should no longer be contained.
If you cannot switch to the EDIT mode in Transaction SE14, which means no modifications are allowed in the customer system, then proceed as follows:

Call function module 'DD_TABL_ACTM' as described above.
Then call Transaction SE14 again and verify that the table has been activated.
As a result, this ensures that the SDCC can be executed.
The menu options in Transaction SE14 are
-> Extras -> Database object -> Check,
as well as
-> Extras -> Runtime object -> Check
inconsistencies should no longer be contained.
If this is not the case, open a CSN message under the BC-DWB-DIC-ED component.