FAQ Data Browser (SE16)
Q.1 The number of "Maximum number of hits" is confined to the selection screen. Following this, when you start selections for which the number of data exceeding the "Maximum number of hits". Why the smallest value in the results list differ with a different value for the "Maximum number of hits"?
To resolve this issue selection must be performed with a WHERE condition is less than or equal to ROWNUM ("<= ROWNUM"). It implies that the first "n" records is read by the system in the database. The data in the database may be unsorted.
Q.2 How to search for special characters?
Using of special characters in texts should be avoided in general. However, special characters can be searched by placing a '#' escape character in front of the special character.
For exampl Text fields contain the character '*', which is used as a wildcard for generic searches in the selection. Now all values containing a character '*' can be listed by using a selection with a field value = *#** .
Q.3 Transaction SE16 result lists display the content of some fields differently from the single record view?
For ex:
- Table Field Display Hit list Display Single record (F7)
- T002 SPRAS b IS
- BSIS HKONT 0000191100 191100
- MARA MEINS ST PC
There are some domains of the table fields for which Conversion exits are defined. These are always run for each dynpro input or output (function 'Display' (F7)).
The hit list is not a dynpro, therefore the conversion exit can not run by default. But, we can include the Conversion exit in processing by choosing the menu option 'Settings' -> 'User Parameters' and activate the 'Respect Conversion Exit' checkbox.
Note: This parameter relates exclusively to the list display, so to all hit lists and to the detailed display (F2) in the case of the ALV (list/grid) display.
Q.4 Why the table in transaction SE16 cannot be changed even if the table is selected as changeable under Attributes in transaction SE11?
The change of table entries depends on the factors listed below:
- Role and changeability of the client
- Delivery class of the table
- If a maintenance view exists for the table
- Authorization
- System changeability
Q.5 Texts from text tables not displayed. Why?
A text table is generally defined for a table that is displayed and maintained in the Data Browser. But also, there are restrictions under which a unique relationship cannot be found by Data Browse and the expected text table does not get displayed:
1.The text table cannot be uniquely determined because several tables are simultaneously defined as a text table for the table to be displayed.
In this case, the system selects one of the text tables. Whichever of the text tables is selected cannot be influenced.
2. Due to foreign key dependency exceeding the text relationship, for example, a foreign key dependency on the client table which does not go with the primary table for which the table is defined as a text table. In this case, the function is not available in this case.
The text table can still be displayed by using the following s given below.
- Only define the text relationship for the primary table.
- Only one text table should be defined for the table.
Q.6 Why only user-specific variants can be created in the ALV list?
Due to some technical reasons, transaction SE16 cannot distinguish between the tables for which a display variant is valid. Therefore note down the table for which display variant is valid. In order to prevent variants from being used for incorrect tables, global variants should be created.
In higher upgrades, this restriction has been lifted.
Q.7 What authorizations a user require to in order to display certain values in transaction SE16?
In transaction SE16 when displaying table contents, the system checks against the authorization object S_TABU_DIS. In order to display a table, the user should display authorization (activity 03) for the authorization group of the respective table. The authorization group results from the table TDDAT. Several tables can be grouped together there in authorization groups. The table to be displayed is assigned to the standard authorization group "&NC&" if the table is not entered in TDDAT.. Therefore, users who may not display any table contents should have no authorization for S_TABU_DIS. Users who should see only certain table contents should have authorization for S_TABU_DIS for a certain group only. All tables that the user may see must then be allocated to this group.
In newer upgrades, the S_TABU_NAM authorization object got added to the authorization concept; this authorization object controls the access to the level of the table name. The system also checks whether user have S_TABU_NAM authorization in the case if the user does not have S_TAB_DIS authorization for a specific table. If the user has an S_TABU_NAM authorization the access is granted to the use.This enhancement is particularly useful if large numbers of tables are not assigned to any table authorization group, but you do not want to assign the S_TABU_DIS authorization for the standard authorization group &NC to many users. It is then better to grant limited S_TABU_NAM authorizations to the relevant users.