Internal tables with empty key?
Each internal table has a primary key. Even standard tables have a table key. Key access is not optimized for standard tables but the primary key plays a role if you use SORT itab without explicit sort fields or for table statements with FROM wa.
How do you declare a table? Pragmatically, often as follows:
DATA: BEGIN OF struct,
col1 TYPE i,
col2 TYPE i,
END OF struct.
DATA itab LIKE TABLE OF struct.
Looks good. But now do the following (in all releases):
DATA: BEGIN OF struct,
col1 TYPE i,
col2 TYPE i,
END OF struct.
DATA itab LIKE TABLE OF struct.
struct-col1 = 3. struct-col2 = 1.
APPEND struct TO itab.
struct-col1 = 2. struct-col2 = 2.
APPEND struct TO itab.
struct-col1 = 1. struct-col2 = 1.
APPEND struct TO itab.
DATA jtab LIKE itab.
jtab = itab.
SORT jtab.
IF jtab = itab.
MESSAGE 'nop!' TYPE 'I'.
ENDIF.
SORT itab does nothing (some people tend to open a ticket now)! Why? Because itab has an empty key!
When you declare a standard table data object without specifiying the primary key, the default key is taken. The default key consists of all character and byte like fields of the table structrure. If the structure contains only numeric fields, duh! The same would have happened if you declared the DEFAULT KEY explicitly. But note that an empty key is not possible for sorted and hashed tables.
If you declare standard table types, the situation can become even more confusing.
TYPES: BEGIN OF struct,
col1 TYPE i,
col2 TYPE i,
END OF struct.
TYPES itab TYPE STANDARD TABLE OF struct.
Here it is not the default key that is declared implicitly, but the table type is generic regarding its key.
To prove that, write
FIELD-SYMBOLS <itab> TYPE itab.
DATA jtab like <itab>.
Yo get a syntax error because the field symbol is generic and cannot be used behind LIKE.To get rid of the error you could add WITH DEFAULT KEY to the TYPES itab statement - and have an empty key again!
So, if you want to work with a table key it is always a good idea to explicitly define the key fields. Using the default key - either by chance or explicitly - is almost always critical because:
- Identifying the key fields only by their data type often leads to unexpected behavior in sorts and other access types.
- The possibility of an empty standard key in standard tables can cause unexpected behavior.
- The standard key can contain many key fields, leading to performance problems.
- In sorted tables and hashed tables the key fields are read-only, which can cause unexpected runtime errors.
But what if you do not care about the key at all? If you simply want to use an internal table as an array that does not depend on key values?
Before release 7.40, some unexpected behavior could arise for such arrays.With release 7.40 you can specify
... WITH EMPTY KEY.
when declaring standard table objects or table types. If you don't care about the key, this new addition is always recommended in order to circumvent all problems with the default key or with a generic key.
TYPES itab TYPE STANDARD TABLE OF string WITH EMPTY KEY.
DATA(itab) = VALUE itab(
( `I'm going slightly mad` )
( `I'm going slightly mad` )
( `It finally happened - happened` )
( `It finally happened - ooh woh` ) ).
Without explicit key declaration the type would not be usable for the inline data declaration shown here. Since I don't care about the key, I use the empty key. A SORT itab without specifying a sort key will do nothing and produce a warning from the syntax check.
Starting with release 7.40 you declare your standard tables either with a good key or an empty key but never with the chancy default key!
