SAP NetWeaver AS ABAP Release 740, ©Copyright 2014 SAP AG. All rights reserved.
ABAP Keyword Documentation → ABAP − Reference → Processing Internal Data → Internal Tables → Processing Statements for Internal Tables → DELETE itab →
DELETE itab - itab_lines
Syntax
... itab [USING KEY keyname] [FROM idx1] [TO idx2]
[WHERE log_exp|(cond_syntax)] ... .
Extras:
1. ... USING KEY keyname
2. ... [FROM idx1] [TO idx2]
3. ... WHERE log_exp
4. ... WHERE (cond_syntax)
Effect
To delete several lines at once, you have to specify at least one of the additions FROM, TO, or WHERE. USING KEY keyname is used to determine the 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
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:
Notes
Example
... [FROM idx1] [TO idx2]
Effect
If you use these additions, only the table rows from row number idx1, or up to row number idx2, are taken into account in 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 taken into account.
If the addition USING KEY is not used, or the primary table key is specified in keyname, the additions FROM and TO can only be used for index tables. In this case, they refer to the row numbers of the primary table index.
If a sorted secondary key is specified in keyname after USING KEY, the additions FROM and TO can be used for all table types and refer to the row numbers of the secondary table index.
idx1 and idx2 are numerical expression positions of operand type i. The following restrictions apply:
... WHERE log_exp
Effect
Static WHERE condition. All rows are processed for which the condition after WHERE is met. 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. Any comparison expression and the predicate expression IS INITIAL can be specified as relational expressions. Other predicates cannot be specified. The components of the internal table must be specified as individual operands and not as part of an expression. Parenthesized character-like data objects cannot be used 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 relevant comparison rules apply to the evaluation.
Notes
... WHERE (cond_syntax)
Effect
Dynamic WHERE Condition 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 WHERE condition) or is initial. The following are not supported in a dynamic WHERE condition:
The syntax in cond_syntax is, as in the ABAP Editor, not case-sensitive. When an internal table is specified, the syntax can be distributed across multiple rows. If cond_syntax 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.
Security Note
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 escape. See Security Risks of Dynamic Programming.
Note
The dynamic WHERE conditions 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.
Example
Deletes all rows in an internal table from row 4. The result is the same as in the example for APPEND ... SORTED BY. The column seatsfree is not required by the SELECT statement but is filled by the program. For this reason, the associated syntax check warning is hidden by the appropriate pragma.
PARAMETERS: p_carrid TYPE sflight-carrid,
p_connid TYPE sflight-connid.
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
FROM sflight
INTO TABLE seats_tab
WHERE carrid = p_carrid AND
connid = p_connid ##too_many_itab_fields.
LOOP AT seats_tab INTO seats.
seats-seatsfree = seats-seatsmax - seats-seatsocc.
MODIFY seats_tab INDEX sy-tabix FROM seats.
ENDLOOP.
SORT seats_tab BY seatsfree DESCENDING.
DELETE seats_tab FROM 4.