ABAP Keyword Documentation → ABAP − Reference → Obsolete Language Elements → Obsolete Processing of Internal Data → Obsolete Internal Table Processing
READ TABLE- obsolete_key
Other versions: 7.31 | 7.40 | 7.54
Obsolete Syntax
READ TABLE itab { { }
| { WITH KEY dobj }
| { WITH KEY = dobj } } [BINARY SEARCH] result.
Alternatives
1. ... { }
2. ... WITH KEY dobj
3. ... WITH KEY = dobj
Addition
Effect
As well as the additions specified in the statement READ TABLE for specifying the individual rows to be read, outside of classes the search key can also be specified in three obsolete forms.
Alternative 1
... { }
Effect
If the search key is not specified explicitly, the internal table itab
must be a
standard table with a
header line. The first row found in the internal table is read for which the values in the columns of the
standard key match the
values in the corresponding components of the header line. Key fields in the header line that only contain
blanks are handled as if they match all values. If all the key fields in the header line only contain
blanks, the first entry in the table is read. The standard key of the internal table cannot contain any byte-like components.
Notes
-
The statement
READ TABLE itab ...
is not the same as the explicit declaration of the header lineitab
as a work areawa
in the statementREAD TABLE itab FROM wa ...
. In the latter, the table key and not the search key of the header field is used for the search. -
The search key can be omitted regardless of the additional obsolete short form (where no explicit target area is specified).
Example
In the following READ
statement (in contrast to the example for
READ TABLE - table_key
) no entry is usually found, since the whole standard
key is compared. In particular, the components deptime
and arrtime
that belong to the standard key of the internal table are of type t
and contain the value "000000" instead of blanks as an
initial value in the header line. Only table entries that contain exactly these values are read.
DATA: spfli_tab TYPE STANDARD TABLE OF spfli
WITH NON-UNIQUE KEY carrid connid
WITH HEADER LINE.
FIELD-SYMBOLS <spfli> TYPE spfli.
SELECT *
FROM spfli
WHERE carrid = 'LH'
INTO TABLE @spfli_tab.
spfli_tab-carrid = 'LH'.
spfli_tab-connid = '0400'.
READ TABLE spfli_tab ASSIGNING <spfli>.
Alternative 2
... WITH KEY dobj
Effect
If a single data object is specified directly after the addition WITH KEY
, the internal table itab
must be a
standard table. The
first row found in the internal table is read whose left-justified content matches the content of the data object dobj
. The data object dobj
expects only
flat data types. In the search,
the start of table rows that are longer than the data object dobj
are handled as if they have the same data type dobj
(casting).
Example
To use the addition WITH KEY dobj
for evaluating specific key fields, a structure
must be created that corresponds to the relevant starting part of the row type. In contrast to the example
for READ TABLE - table_key
,
in the following program section, the client column mandt
of the table spfli_tab
must be respected by the search key.
DATA: spfli_tab TYPE STANDARD TABLE OF spfli
WITH NON-UNIQUE KEY carrid connid.
DATA: BEGIN OF key_struc,
mandt TYPE spfli-mandt VALUE '000',
carrid TYPE spfli-carrid VALUE 'LH',
connid TYPE spfli-connid VALUE '0400',
END OF key_struc.
FIELD-SYMBOLS <spfli> TYPE spfli.
SELECT *
FROM spfli
WHERE carrid = 'LH'
INTO TABLE @spfli_tab.
READ TABLE spfli_tab WITH KEY key_struc ASSIGNING <spfli>.
Alternative 3
... WITH KEY = dobj
Effect
If the addition WITH KEY
is followed by a single data object after an "equals"
sign, the first row found in the internal table itab
is read whose entire
content corresponds to the content of the data object dobj
. It must be possible
to convert the data object dobj
to the row type of the internal table. If
the data type of dobj
does not match the row type of the internal table, a conversion is performed for the comparison in accordance with the
conversion rules.
Note
This statement has the same function as specifying the
pseudo component table_line
as a
free key, and is replaced by this component.
READ TABLE itab WITH KEY table_line = dobj ...
Example
Determines (obsoletely) whether a row in an internal table exists with an elementary row type. The comment lines show the generally valid syntax with the pseudo-component table_line
.
DATA itab TYPE TABLE OF i WITH EMPTY KEY.
itab = VALUE #( FOR j = 1 UNTIL j > 10 ( j ) ).
READ TABLE itab WITH KEY = 4
TRANSPORTING NO FIELDS.
* READ TABLE itab WITH KEY table_line = 4
* TRANSPORTING NO FIELDS.
IF sy-subrc = 0.
...
ENDIF.
Addition
... BINARY SEARCH
Effect
The addition BINARY SEARCH
produces a binary search of the table, not linear. The same prerequisites and restrictions apply as when using the addition with a
free search key. Before the correct row can be found, the internal table must be sorted in ascending order as follows:
- If the search key is not specified explicitly, by the components of the standard key.
-
If the search key is specified using
WITH KEY dobj
, by its left-justified content in the length of the data object. -
If the search key is specified using
WITH dobj
, by the full table row.
Note
The fact that the addition BINARY SEARCH
requires a different sorting in
each of the obsolete variants can be confusing and produce unexpected behavior. For this reason, the
addition should not be used in the case of the obsolete variants and the non-obsolete variants of READ TABLE
used instead.
Exceptions
Non-Handleable Exceptions
-
Cause: The key has stricter alignment requirements than the individual table rows.
Runtime error:READ_BAD_KEY_ALIGN
-
Cause: The key is longer than a table row and cannot be shortened.
Runtime error:READ_BAD_KEY_PARTIAL