Skip to content

ABAP Keyword Documentation →  ABAP − Reference →  Processing Internal Data →  Internal Tables →  Processing Statements for Internal Tables →  DELETE itab 

DELETE itab - duplicates

Quick Reference

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, no rows are deleted. If this is known statically, the syntax check produces a warning.


Notes

  • The use of ADJACENT DUPLICATES usually 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 city_connections.

TYPES: BEGIN OF city_connection, 
         cityfrom TYPE spfli-cityfrom, 
         cityto   TYPE spfli-cityto, 
         distid   TYPE spfli-distid, 
         distance TYPE spfli-distance, 
       END OF city_connection. 

DATA city_connections TYPE SORTED TABLE OF city_connection 
                     WITH NON-UNIQUE KEY cityfrom cityto 
                                         distid distance. 

SELECT cityfrom, cityto, distid, distance 
       FROM spfli 
       INTO TABLE @city_connections. 

DELETE ADJACENT DUPLICATES FROM city_connections. 

cl_demo_output=>display( city_connections ). 

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 does not influence the processing order when a secondary hash key is specified.


Example

The statement DELETE deletes all multiple numbers from the internal table itab. The table then contains a maximum of ten rows.

DATA itab TYPE TABLE OF i WITH EMPTY KEY 
               WITH NON-UNIQUE SORTED KEY skey COMPONENTS table_line. 

DATA(rnd) = cl_abap_random_int=>create( seed = + sy-uzeit 
                                      min  = 1 
                                       max  = 10 ). 

itab = VALUE #( FOR i = 1 UNTIL i > 100 ( rnd->get_next( ) ) ). 

DELETE ADJACENT DUPLICATES FROM itab USING KEY skey. 

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.


Example

Reads specific data from two tables in the ITF framework. Here, DOKIL is the index table for DOKHL. After the multiple numbers are deleted, it is expected that both tables contain the same number of rows. The table declared inline, >dokhl_tab, has an empty primary key, which means that the component object is specified explicitly using COMPARING.

SELECT object 
       FROM dokil 
       WHERE id = 'SD' AND 
             object LIKE 'AB%' AND 
             langu = @sy-langu AND 
             typ   = 'E' 
       ORDER BY object 
       INTO TABLE @DATA(dokil_tab). 

SELECT object 
       FROM dokhl 
       WHERE id = 'SD' AND 
             object LIKE 'AB%' AND 
             langu = @sy-langu AND 
             typ   = 'E' 
       ORDER BY object, dokversion DESCENDING 
       INTO TABLE @DATA(dokhl_tab). 

DELETE ADJACENT DUPLICATES FROM dokhl_tab COMPARING object. 

ASSERT lines( dokhl_tab ) = lines( dokil_tab ). 

Continue

Internal Tables, Deleting Duplicate Rows