-
Notifications
You must be signed in to change notification settings - Fork 0
User specific Log Level
Table name: /USI/BAL_LV_USER
Maintained via: SM30
If the Product specific Log Level does not produce a log, that is verbose enough to analyze an issue, it can be overwritten as a current setting.
The setting will affect exactly one user. If you need to increase the log level for an entrie client (e.g. during a hypercare phase) the Client specific Log Level would be the appropriate solution.
You can change these settings directly in the productive system.
The structure of all customizing tables has been documented in a unified format.
General Information explains how this documentation is to be read.
Fieldname | Fieldtype | Filter-Priority | Description |
---|---|---|---|
MANDT | Key |
Client | |
UNAME | Key |
User affected by the issue to analyze | |
ENDDA | Key |
Expiration date of the entry. Only entries having an ENDDA >= SY-DATUM will be considered. | |
LOG_OBJECT | Filter |
1 | Log object |
SUB_OBJECT | Filter |
2 | Sub object |
LOG_LEVEL | Data |
Assigned Log-Level | |
AUTO_SAVE | Data |
ABAP_TRUE: Return 1 for AUTO_SAVE_PACKAGE_SIZE (see: Product specific Log Level) |
If no suitable customizing can be found, the following default values will be applied.
Fieldname | Default |
---|---|
LOG_LEVEL | 0 (Log completely deactivated) |
AUTO_SAVE | ABAP_FALSE: Return 0 for AUTO_SAVE_PACKAGE_SIZE (see: Product specific Log Level) |
Setting the auto-save flag saves all messages directly.
This is particularly useful if an application fails to call the save method, for example, due to dumps or infinite loops over multiple modularization units. Setting the auto-save flag can be very helpful in narrowing down the possible causes of the problem.
Setting the flag has a negative impact on performance, as every single message is directly written to the database.
Since an enhanced log level might create a lot of data over time the table maintenance view will enforce an expiration date for each entry.
The maximum validity in days will be determined by calling a BAdI, that is shipped with a default implementation.
If needed the default can be overwritten by adding another BAdI implementation (Transaction SE19).
Label | Value |
---|---|
Enhancement Spot | /USI/BAL_CUSTOMIZING_VALIDITY |
BAdI | /USI/BAL_CUST_VALIDITY_USER |
Interface | /USI/IF_BAL_CUST_VALIDITY |
Filters | Log Object, Sub Object |
Default value | 14 (Days) |