ABAP Keyword Documentation → ABAP - Reference → Processing Internal Data → Internal Tables → Processing Statements for Internal Tables → DELETE itab
DELETE itab - duplicates
Other versions: 7.31 | 7.40 | 7.54
Syntax
... ADJACENT DUPLICATES FROM itab [USING KEY keyname]
[COMPARING {
comp1 comp2 ...}|{ALL FIELDS}] ...
Extras
1. ... USING KEY keyname
2. ... COMPARING {comp1 comp2 ...}|{ALL FIELDS}
Effect
Using these additions, the statement DELETE deletes all rows in certain groups
of rows, except for the first row of the group. These are groups of rows that are sequential and have
the same content in certain components. If the addition COMPARING is not
specified, the groups are determined by the content of the key fields of the table key being used. If no explicit table key is specified, the
primary table key is used implicitly.
The order of the table rows that are used to form the groups is determined by the table key being used.
If no key keyname is specified after USING KEY,
the order is the same as when processing a statement LOOP without explicit specification of a key.
Rows are considered to be duplicate if the content of neighboring row is the same in the components examined. In the case of multiple duplicate rows following one another, all the rows (except for the first) are deleted.
If the primary table key is used to access a standard table and the key is empty, then no rows are deleted. If this is statically identifiable, the syntax check produces a warning.
Notes
-
The use of
ADJACENT DUPLICATESusually requires a suitable sorting by the components compared in the statement. -
When using the primary table key, note that this key can be the standard key, which can also have unexpected consequences:
- For structured row types, the standard key covers all character-like and byte-like components.
- The standard key of a standard table can be empty.
Example
Deletes all multiple rows with respect to the primary key in the internal table connection_tab.
The result of this example corresponds to the one in the example for the position specification for INSERT.
DATA: BEGIN OF connection,
cityfrom TYPE spfli-cityfrom,
cityto TYPE spfli-cityto,
distid TYPE spfli-distid,
distance TYPE spfli-distance,
END OF connection.
DATA connection_tab LIKE SORTED TABLE OF connection
WITH NON-UNIQUE KEY cityfrom cityto
distid distance.
SELECT cityfrom, cityto, distid, distance
FROM spfli
INTO TABLE @connection_tab.
DELETE ADJACENT DUPLICATES FROM connection_tab.
Addition 1
... USING KEY keyname
Effect
The USING KEY addition can be used to specify a table key in
keyname used to carry out the processing. The specified table key influences the order in which the table rows are accessed, and the evaluation of the remaining conditions.
If the primary table key is specified, the processing behaves in the same way as when no key is explicitly specified. If a secondary table key is specified, the order in which the rows are accessed is as follows:
-
Sorted key specified
The rows are processed by ascending row number in the secondary table index -
Hash key specified
The rows are processed in the order in which they were inserted into the table.
Note
Unlike the processing of a hashed table when a primary key is used, a preceding sort using the statement
SORT has no influence on the processing order when a secondary hash key is specified.
Addition 2
... COMPARING {comp1 comp2 ...}|{ALL FIELDS}
Effect
If the addition COMPARING is specified, the groups are determined either
by the content of the specified components comp1 comp2 ... or the content
of all components ALL FIELDS. The specification of individual components comp is made as described in the section
Specification of Components. Access to class attributes is possible using the object component selector.