DELETE itab - itab_lines
To delete more than one row, at least one of the additions
WHERE must be specified. USING KEY
keyname is used to determine the table key to which the additions refer.
If you specify more than one of the additions, those rows are deleted that result from the intersection of the individual additions.
... USING KEY keyname
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.
Unlike the processing of a hashed table when a primary key is used, a preceding sort using the statement
SORThas no influence on the processing order when a secondary hash key is specified.
If a secondary table key is specified, any
WHEREcondition also specified must be optimizable. Otherwise a syntax error occurs or an exception is raised.
DELETE deletes the first three rows of the internal table
itab because they occur from row 4 in the secondary table index of the secondary key
DATA itab TYPE TABLE OF i WITH EMPTY KEY
WITH UNIQUE SORTED KEY skey COMPONENTS table_line.
itab = VALUE #( ( 6 ) ( 5 ) ( 4 ) ( 3 ) ( 2 ) ( 1 ) ).
DELETE itab USING KEY skey FROM 4.
... [FROM idx1] [TO idx2]
If these additions are used, only the table rows from row number
up to row number
idx2, are respected if the table index used. If only
FROM is specified, all rows of the table from row number
idx1 up to
and including the last row are taken into account. If only
TO is specified, all rows in the table from the first row up to row number
idx2 are respected.
If the addition
USING KEY is not used, or the
primary table key
is specified in
keyname, the additions
TO can only be used for
index tables. In this case, they refer to the row numbers of the
primary table index.
numeric expression positions of operand type
i. The following restrictions apply:
If the value of
idx1is less than or equal to 0, a runtime error occurs. If the value of
idx1is greater than the total number of table rows, no processing takes place.
If the value of
idx2is less than or equal to 0, a runtime error occurs. If the value of
idx2is greater than the number of table rows, it is set to the number of table rows.
If the value of
idx2is less than the value of
idx1, no processing takes place.
DELETE FROM itab has the statement
DELETE FROM dbtab with identical syntax. If an internal table has the same name as a database table, a statement like this accesses the internal table.
DATA: carrid TYPE sflight-carrid VALUE 'LH',
connid TYPE sflight-connid VALUE '0400'.
)->add_field( CHANGING field = carrid
)->add_field( CHANGING field = connid )->request( ).
DATA: BEGIN OF seats,
fldate TYPE sflight-fldate,
seatsocc TYPE sflight-seatsocc,
seatsmax TYPE sflight-seatsmax,
seatsfree TYPE sflight-seatsocc,
END OF seats.
DATA seats_tab LIKE STANDARD TABLE OF seats.
SELECT fldate, seatsocc, seatsmax, seatsmax - seatsocc AS seatsfree
WHERE carrid = @carrid AND
connid = @connid
INTO TABLE @seats_tab.
SORT seats_tab BY seatsfree DESCENDING.
DELETE seats_tab FROM 4.
cl_demo_output=>display( seats_tab ).
... WHERE log_exp
WHERE condition. All rows are processed for which the condition after
WHERE is met. If a static
WHERE condition is specified,
the row type of the internal table must be known statically.
WHERE can be specified for all table categories.
A logical expression
log_exp can be specified after
WHERE, in which the first operand of each
relational expression is a
component of the internal table. The following can be specified as relational expressions:
No other predicates can be specified. The components of the internal table must be specified as individual operands and not as part of an expression. You cannot use parenthesized character-like data objects to specify a component dynamically here. The remaining operands of a relational expression are general expression positions at which any suitable individual operands or expressions can be specified, but no components of the internal table. The specified components can have any data type. The usual comparison rules apply to the evaluation. Here, a different rule applies to a string expression on the right side than to general logical expressions.
- When standard tables
are accessed without a secondary key being specified, the access is not optimized. This means that all
rows of the internal table are tested for the logical expression of the
- When using a sorted key or a
hash key (that is, when accessing a
sorted table, a
hashed table, or a
secondary table key),
an attempt is made to optimize the access as described under
Optimization of the
WHERECondition. If the corresponding prerequisites are not met:
- the entire logical expression (or a part of the expression) can be transformed to a key access,
- the transformable part of the logical expression has the same result as the resulting key access,
WHERE condition cannot specify any duplicate or overlapping keys.
Duplicate key components can, however, be specified in the part of the logical expression whose relational expressions do not make a contribution to the optimized access.
When using a
WHEREcondition, note that the comparison rules for incompatible data types apply when comparing incompatible data objects. Here, the data types involved determine which operand is converted. If the additions
WITH TABLE KEYand
WITH KEYof the statement
READare used or if the appropriate keys are specified in table expressions, however, the content of the specified data objects is always converted to the data type of the columns before the comparison. This can produce varying results.
If possible, all operands of the logical expression should be in
compatible pairs, so enabling
WHEREcondition to be optimized.
If a comparison expression with a
ranges table is specified after
INas a logical expression, note that the expression at the initial table is always true and then all rows are edited.
Optimizations of the
WHEREcondition affect searches for the rows to delete but do not affect, for example, updates of the primary index of a standard table.
In two optimized
DELETE statements, deletes a row using a fully specified unique primary table key and deletes multiple rows by specifying a non-unique secondary table key.
DATA spfli_tab TYPE SORTED TABLE OF spfli
WITH UNIQUE KEY carrid connid
WITH NON-UNIQUE SORTED KEY skey COMPONENTS cityfrom cityto.
INTO TABLE @spfli_tab.
DELETE spfli_tab WHERE carrid = 'LH' AND
connid = '0400'.
DELETE spfli_tab USING KEY skey WHERE cityfrom = 'FRANKFURT' AND
cityto = 'NEW YORK'.
... WHERE (cond_syntax)
cond_syntax can be specified as a character-like data object or
standard table with
character-like row type that, when the statement is executed and with the following exceptions, contains
the syntax of a logical expression (in accordance with the rules of the static
condition) or is initial. The following are not supported in a dynamic
- String expressions and bit expressions
- String functions and bit functions
Time stamp functions with the exception of
- Constructor expressions
The syntax in
cond_syntax is not case-sensitive (as in the static syntax).
When an internal table is specified, the syntax can be distributed across multiple rows. If
is initial when the statement is executed, the logical expression is true. Invalid logical expressions raises an exception from the class CX_SY_ITAB_DYN_LOOP.
If used wrongly, dynamic programming techniques can present a serious security risk. Any dynamic content
that is passed to a program from the outside must be checked thoroughly or escaped before being used
in dynamic statements. This can be done using the system class CL_ABAP_DYN_PRG or the predefined function
Security Risks Caused by Input from Outside.
WHERE condition is not evaluated for a blank table for optimization
reasons. Therefore, if an internal table is blank, and a logical expression has errors, no exception is raised.
Deletes the rows of n internal table using a condition that can be entered for the table rows.
DATA condition TYPE string VALUE '<= 0'.
cl_demo_input=>request( CHANGING field = condition ).
condition = `table_line ` && condition.
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 = 20 ).
itab = VALUE #( FOR i = 1 UNTIL i > 100
( rnd->get_next( ) - 10 ) ).
DELETE itab USING KEY skey WHERE (condition).
cl_demo_output=>display( itab ).
CATCH cx_sy_itab_dyn_loop INTO DATA(exc).