Table expressions with the syntax
... itab[ ... ] ...
are a new way for accessing table lines in operand positions. You can view a table expression simply as a short form of a READ TABLE statement. The result of a table expression is a single table line. All you have to know is the syntax that does the same as a given READ TABLE statement.
If a table line is not found, the exception CX_SY_ITAB_LINE_NOT_FOUND is raised. No sy-subrc from expressions, of course.
The operand positions where table expressions can be used are read positions but also some write positions where you can modify the resulting table line. Table expressions are LHS-expressions!
The assignment of the table expression
wa = itab[ idx ].
does the same as
READ TABLE itab INDEX idx INTO wa.
The assignment of the table expression
wa = itab[ KEY key INDEX idx ].
does the same as
READ TABLE itab INDEX idx USING KEY key INTO wa.
The assignment of the table expression
wa = itab[ col1 = ... col2 = ... ].
does the same as
READ TABLE itab WITH KEY col1 = ... col2 = ... INTO wa.
Key access using a table key
The assignment of the table expressions
wa = itab[ KEY key col1 = ... col2 = ... ].
wa = itab[ KEY key COMPONENTS col1 = ... col2 = ... ].
do the same as
READ TABLE itab WITH TABLE KEY key COMPONENTS col1 = ... col2 = ... INTO wa.
With READ TABLE you can read into a work are, assign a field symbol or set a reference. The result of table expressions can be influenced accordingly.
as a rule works like READ TABLE ... ASSIGNING ... . The temporary result of the expression is a field symbol.
forces the expression to work like READ TABLE ... INTO ... . The temporary result of the expression is a data object.
forces the expression to work like READ TABLE ... REFERENCE INTO ... . The temporary result of the expression is a reference variable.
While the third case is important, if you want to work with references to table lines, the results of the other two cases are normally transparent to the user. You don't have to care how the intermediate result is represented internally. But there are some performance considerations. The same rules when to use what hold for table expressions as for READ TABLE. Therfeore, the syntax checker might kindly remind you from time to time to place the VALUE operator in front of a table expression (or to leave it away ...).
The following chainings with table expressions are possible:
... itab[ ...]-comp
... struct-comp[ ... ] ...
... itab[ ... ][ ... ] ...
and combinations of those
TYPES:
BEGIN OF struc1,
col1 TYPE i,
col2 TYPE i,
END OF struc1,
itab1 TYPE TABLE OF struc1 WITH EMPTY KEY,
itab2 TYPE TABLE OF itab1 WITH EMPTY KEY,
BEGIN OF struc2,
col1 TYPE i,
col2 TYPE itab2,
END OF struc2,
itab3 TYPE TABLE OF struc2 WITH EMPTY KEY.
DATA(itab) = VALUE itab3(
( col1 = 1 col2 = VALUE itab2(
( VALUE itab1(
( col1 = 2 col2 = 3 )
( col1 = 4 col2 = 5 ) ) )
( VALUE itab1(
( col1 = 6 col2 = 7 )
( col1 = 8 col2 = 9 ) ) ) ) )
( col1 = 10 col2 = VALUE itab2(
( VALUE itab1(
( col1 = 11 col2 = 12 )
( col1 = 13 col2 = 14 ) ) )
( VALUE itab1(
( col1 = 15 col2 = 16 )
( col1 = 17 col2 = 18 ) ) ) ) ) ).
* Reading the column with value 13 with READ TABLE statements
READ TABLE itab INTO DATA(wa1) INDEX 2.
READ TABLE wa1-col2 INTO DATA(wa2) INDEX 1.
READ TABLE wa2 INTO DATA(wa3) INDEX 2.
DATA(num1) = wa3-col1.
* Reading the column with value 13 with chained table expressions
DATA(num2) = itab[ 2 ]-col2[ 1 ][ 2 ]-col1.
Unbelievable, is this still ABAP?
... itab[ ... ] ...
are a new way for accessing table lines in operand positions. You can view a table expression simply as a short form of a READ TABLE statement. The result of a table expression is a single table line. All you have to know is the syntax that does the same as a given READ TABLE statement.
If a table line is not found, the exception CX_SY_ITAB_LINE_NOT_FOUND is raised. No sy-subrc from expressions, of course.
The operand positions where table expressions can be used are read positions but also some write positions where you can modify the resulting table line. Table expressions are LHS-expressions!
Specifiying the line
Index access using the primary index
The assignment of the table expression
wa = itab[ idx ].
does the same as
READ TABLE itab INDEX idx INTO wa.
Index access using a secondary index
The assignment of the table expression
wa = itab[ KEY key INDEX idx ].
does the same as
READ TABLE itab INDEX idx USING KEY key INTO wa.
Access using a free key
The assignment of the table expression
wa = itab[ col1 = ... col2 = ... ].
does the same as
READ TABLE itab WITH KEY col1 = ... col2 = ... INTO wa.
Key access using a table key
The assignment of the table expressions
wa = itab[ KEY key col1 = ... col2 = ... ].
wa = itab[ KEY key COMPONENTS col1 = ... col2 = ... ].
do the same as
READ TABLE itab WITH TABLE KEY key COMPONENTS col1 = ... col2 = ... INTO wa.
Influencing the result
With READ TABLE you can read into a work are, assign a field symbol or set a reference. The result of table expressions can be influenced accordingly.
- ... itab[ ... ] ...
as a rule works like READ TABLE ... ASSIGNING ... . The temporary result of the expression is a field symbol.
- ... VALUE type( itab[ ... ] ) ...
forces the expression to work like READ TABLE ... INTO ... . The temporary result of the expression is a data object.
- ... REF type( itab[ ... ] ) ...
forces the expression to work like READ TABLE ... REFERENCE INTO ... . The temporary result of the expression is a reference variable.
While the third case is important, if you want to work with references to table lines, the results of the other two cases are normally transparent to the user. You don't have to care how the intermediate result is represented internally. But there are some performance considerations. The same rules when to use what hold for table expressions as for READ TABLE. Therfeore, the syntax checker might kindly remind you from time to time to place the VALUE operator in front of a table expression (or to leave it away ...).
Chainings
The following chainings with table expressions are possible:
... itab[ ...]-comp
... struct-comp[ ... ] ...
... itab[ ... ][ ... ] ...
and combinations of those
Fun example
TYPES:
BEGIN OF struc1,
col1 TYPE i,
col2 TYPE i,
END OF struc1,
itab1 TYPE TABLE OF struc1 WITH EMPTY KEY,
itab2 TYPE TABLE OF itab1 WITH EMPTY KEY,
BEGIN OF struc2,
col1 TYPE i,
col2 TYPE itab2,
END OF struc2,
itab3 TYPE TABLE OF struc2 WITH EMPTY KEY.
DATA(itab) = VALUE itab3(
( col1 = 1 col2 = VALUE itab2(
( VALUE itab1(
( col1 = 2 col2 = 3 )
( col1 = 4 col2 = 5 ) ) )
( VALUE itab1(
( col1 = 6 col2 = 7 )
( col1 = 8 col2 = 9 ) ) ) ) )
( col1 = 10 col2 = VALUE itab2(
( VALUE itab1(
( col1 = 11 col2 = 12 )
( col1 = 13 col2 = 14 ) ) )
( VALUE itab1(
( col1 = 15 col2 = 16 )
( col1 = 17 col2 = 18 ) ) ) ) ) ).
* Reading the column with value 13 with READ TABLE statements
READ TABLE itab INTO DATA(wa1) INDEX 2.
READ TABLE wa1-col2 INTO DATA(wa2) INDEX 1.
READ TABLE wa2 INTO DATA(wa3) INDEX 2.
DATA(num1) = wa3-col1.
* Reading the column with value 13 with chained table expressions
DATA(num2) = itab[ 2 ]-col2[ 1 ][ 2 ]-col1.
Unbelievable, is this still ABAP?
No comments:
Post a Comment