What does it do? If a table expression> is specified in a general expression position> or in a functional operand position>, the read line can be passed to this position in three different ways:
As a field symbol> to which the table line is assigned.
As a work area> that contains the content of the table line.
As a data reference variable> that points to the table line. The result of a table expression is only available temporarily. It is used as an operand of a statement and then deleted again. It is deleted when the current statement is closed or after the evaluation of a relational expression once the truth value is determined. The ways of how a table expression is specified shown here determine how the table line is returned. A default value default>> can be specified for the result in two alternatives.
ABAP Alternative 1 ... itab[ ... ]>
ABAP Alternative 2 ... VALUE type( itab[ ... ] $[default$] )>
What does it do? Both alternatives can be specified in all read positions for table expressions in which the line type matches the operand type (see also Chainings>). The result is either a temporary field symbol, a temporary work area, or the value is assigned directly to a target variable. If the value operator VALUE> is used, an optional default value default>> can be specified for cases where no table line is found.
If the table expression is not specified as an operand of the value operator VALUE>> or of the reference operator REF>>, the result is usually a temporary field symbol typed with the line type of the internal table and to which the table line found is assigned. For performance reasons, there are exceptions to this rule in the following cases:
If the table expression is specified as the right side of an assignment>, the content of the table line or a component> is assigned directly to the target variable instead of a temporary result being produced.
If the line type of the internal table is flat and narrow and used directly in the operand position, for example as an operand of an arithmetic expression or as a formal parameter for an actual parameter where pass by value is declared, the result is a temporary work area.
If the table expression is specified as an operand of the value operator VALUE>>, the result is always a temporary work area, unless the expression is specified as the right side of an assignment>. The data type of the work area is determined by specifying type>> for the constructor expression:
If the #> character is specified for type> and the data type required in an operand position is known uniquely and completely, the operand type is used. Otherwise the line type of the internal table or of a chaining> specified here is applied.
If a non-generic data type dtype> is specified for type>, the line type of the internal table must be compatible with this data type or be convertible to this data type. In this case, the temporary work area has the data type dtype> and the data of the line found is converted to this data type, if necessary, in accordance with the conversion rules>. If the expression is specified as the right side of an assignment>, the content of the table line or component> is also assigned directly when using VALUE>. In most cases, it is transparent and irrelevant, whether the result exists as a field symbol or as a work area. In some cases, however, performance reasons or to avoid side effects, it may be beneficial if the standard behavior is suspended and data is written explicitly to a temporary work area instead. BEGIN_SECTION VERSION 5 OUT
For notes about performance, see the programming guideline Output Behavior>. This guideline should also be respected when using table expressions. In the extended program checks>, a syntax check warning, that can be hidden by a pragma occurs if the rule appears to be violated. END_SECTION VERSION 5 OUT
Side effects can occur if the line of the internal table to which the temporary field symbol points is modified while the binding to the field symbol persists.
Latest notes:
A table expression whose result is a temporary field symbol can be viewed as a short form of the statement READ TABLE>> with the addition ASSIGNING >> and a table expression whose result is a temporary work area can be viewed as a short form of this statement with the addition INTO>>. The corresponding rules and notes apply.
More specifically, restrictions> regarding the modification of key fields must be respected in write positions in the case of table expressions whose result is a temporary field symbol.
In variant 1, the compilation decides whether the result is a field symbol or a work area, not the table content at runtime.
Chainings> of table expressions can also be specified as an argument of the value operator VALUE>. This argument then controls the final result of the chaining.
Unlike when using the value operator VALUE>> for constructing values, elementary types or reference types can also be specified for table expressions for type>. NON_V5_HINTS ABAP_HINT_END
ABAP_EXAMPLE_VX5 The following program excerpt shows table expression with field symbols and work areas as a result. ABEXA 01342
Temporary work areas are passed in the assignments to number> and text>. The VALUE> operator of the second assignment expresses this explicitly, but is not necessary.
In the passes to the formal parameter of the method meth>, the results are temporary field symbols by default. In two cases, the VALUE> operator forces a work area explicitly. In the extended program checks, all passes produces syntax check warnings that can be hidden here using the pragma ##operator>.
In the pass to the formal parameter p1>, using a field symbol by default is bad for performance, since the line is a flat narrow table line. The VALUE> operator is recommended instead.
In the pass to the formal parameter p2>, specifying a work area explicitly is bad for performance, since the line is a deep table line. The VALUE> operator is not recommended here.
In the pass to the formal parameter p3>, specifying a work area explicitly is bad for performance, since the line is a deep table line. The VALUE> operator is not recommended here.
When specifying the internal table using a generically typed field symbol itab>, using the temporary field symbol by default does not produce a syntax check warning, since no fixed work area can be derived here. ABAP_EXAMPLE_END
ABAP_EXAMPLE_ABEXA Table Expressions, Side Effects> ABAP_EXAMPLE_END
What does it do? This alternative can be specified in all read positions for table expressions in which a data reference variable with a suitable type is expected. If a table expression is used as an argument of a constructor expression with the reference operator REF>>, the result is a temporary data reference variable that points to the found table line. If no table line is found, an optional default value default>> can be specified. The static type> of the reference variable is determined by specifying type >> for the constructor expression:
If the #> character is specified for type>, the line type of the internal table is used as the static type.
If a non-generic data type dtype> or the generic data type data>> is specified for type >, they determine the static type of the result. A non-generic data type, dtype>, must be compatible with the line type of the internal table. If the reference operator REF> > is specified in front of a chaining> whose result is a component of a structured table line, it creates a reference to this component. In this case, no substring accesses +off(len)>> can be specified after the component.
Latest notes:
A table expression whose result is a temporary data reference variable can be viewed as a short form of the statement READ TABLE>> with the addition REFERENCE INTO>>. The corresponding rules and notes apply.
More specifically, in the case of a table expression whose result is a temporary data reference variable, the restrictions> on the modification of key fields are respected when dereferencing write positions.
The static type of the temporary data reference variable can only be the line type of the internal table or be completely generic.
Chainings> of table expressions can also be specified as an argument of the reference operator REF>, which then controls the final result of the chaining. NON_V5_HINTS ABAP_HINT_END
ABAP_EXAMPLE_VX5 The following program corresponds to the example for READ TABLE REFERENCE INTO>>, but the statement READ> has been replaced by a table expression in the constructor expression REF>. ABEXA 01343 ABAP_EXAMPLE_END