SAP INTO CLAUSE ABAP Statements Get Example source ABAP code based on a different SAP table
ABAP Statement
• ( ) SELECT INTO
• , SELECT INTO
• INTO SELECT
• CORRESPONDING FIELDS OF SELECT INTO
• APPENDING SELECT
• TABLE SELECT INTO
• CORRESPONDING FIELDS OF TABLE SELECT INTO
SELECT>, INTO>, APPENDING> Short Reference > ABAP_SYNTAX ... ${ INTO (elem1>, elem2>, ...) $} $| ${ INTO $[CORRESPONDING FIELDS OF$] wa> $[ indicators>$] $} $| ${ INTO$|APPENDING $[CORRESPONDING FIELDS OF$] TABLE itab> $[ indicators>$] $[PACKAGE SIZE n$] $} $[ extended_result> $] $[ creating> $] ... .> ABAP_ALTERNATIVES: 1 ... INTO (elem1, elem2, ...)> 2 ... INTO $[CORRESPONDING FIELDS OF$] wa ...> 3 ... INTO$|APPENDING $[CORRESPONDING FIELDS OF$] TABLE itab ... > What does it do? The additions INTO> or APPENDING> construct the INTO> clause of a SELECT>>, WITH> >, or FETCH>> statement. They define which ABAP data objects are assigned the data of the result set of a query and how this assignment is made. The following options are available: An assignment to a parenthesized comma-separated list of individual elementary data objects elem1>>, elem2>>, .... specified after INTO>. An assignment to a single work area wa >> specified after INTO>. An assignment to an internal table itab>> specified after INTO> or APPENDING>. The data objects elem1>>, elem2>>, ...., wa>>, and itab>> can be specified as existing host variables> or declared inline using @DATA>> or @FINAL>>. An addition NEW>> makes it possible to create target areas implicitly as anonymous data objects>. The additions have the following meaning: In writes to work areas wa> and internal tables itab>, CORRESPONDING FIELDS OF> can be used to assign columns of the result set to identically named components of structured target areas. In writes to internal tables, PACKAGE SIZE> can be used to split lines of the result set into packages. indicators>> can be used to specify indicators. Currently, a null indicator > can be specified with information about whether a column of the result set contains the null value. extended_result>> can be used to provide an extended result in a result object. It may be necessary to use creating>> to define whether an LOB> of the result set linked with an LOB handle> is a data stream> or a locator>. These additions can all be used together with the following exceptions: The addition CORRESPONDING FIELDS OF> cannot be used together with inline declarations @DATA>> or @FINAL>> for wa> or itab >. The addition APPENDING> cannot be specified together with NEW>>. If the target area is specified using field symbols or reference variables, and a SELECT> loop is closed using ENDSELECT>>, the data object referenced by a field symbol or reference variable is identified exactly once when the loop is entered. This data object is used as a target area in each loop pass. Any modifications to the assignment of a field symbol or reference variable within the loop are ignored. BEGIN_SECTION SAP_INTERNAL_HINT Before ABAP_740_SP02 it was the other way round. The assignment of a field symbol or reference variable was evaluated for each loop pass and the current data object was used. The LOOP AT> statement also does it the other way. END_SECTION SAP_INTERNAL_HINT The INTO> clause must be the final clause of a main query> and the additions UP TO>>, OFFSET>>, and abap_options>> must be placed after the INTO> clause. Latest notes: The addition NEW>> or other methods for creating anonymous data objects> can be used to create suitable data objects for dynamically specified FROM> clauses> or SELECT> lists>. Whether data should better be read into an internal table or a work area depends on the type of further processing: If data is required only once in a program, it should be imported into a work area, row by row, using a SELECT> loop. Reading data into an internal table requires more memory space without compensating this disadvantage with a considerably higher reading speed. If, on the other hand, data is required many times in a program, it should be read into an internal table. The disadvantage of the increased memory requirement is more than compensated for here by the advantage of a once-only selection. If data is to be imported into an internal table, it is better to import it once into an internal table than to read it, row by row, into a work area and insert its content in the internal table. The INTO> clause and its rules are not affected by the implicit client handling> of ABAP SQL. In particular, the client column of a target structure can be filled with other values than the client ID, for example when assigning individually specified columns of a select list>. Reference variables for LOB handles or LOB handle structures cannot currently be specified after the statement FETCH>. NON_V5_HINTS The statement SELECT> also has an obsolete short form>, in which INTO> or APPENDING> can be omitted. Outside the ABAP_STRICT_760 strict mode / of the syntax check from ABAP_RELEASE ABAP_760 , the INTO> clause does not have to be the last clause of a main query>. Host variables without the escape character @> are obsolete>. The escape character @> must be specified in the strict modes> of the syntax check from ABAP_RELEASE ABAP_740_SP05 . ABAP_HINT_END ABAP Alternative 1 ... INTO (elem1, elem2, ... )> What does it do? Specifies a parenthesized and comma-separated list of elementary data objects elem1>>, elem2>>, ... as target areas of the INTO> clause. This specification is only possible if the columns of the result set are defined using one or more explicitly specified columns col_spec>> in the SELECT> list>. Each of the data objects elem1>>, elem2>>, ... can be specified as existing host variables> or declared inline using @DATA>> or @FINAL>>. The addition NEW>> allows the creation of anonymous data objects. The comma-separated list must have the same number of elements as columns in the result set. The content of the columns in the result set is assigned to the data objects specified in the list from left to right in accordance with the order specified after SELECT>. Assignment rules> apply to the individual assignments. If an LOB> is assigned to a reference variable for LOB handles>, an LOB handle is created>. If an offset/length is specified> to access a data object, +off> must not be omitted. If the result set is empty, the data objects remain unchanged. If a catchable exception is raised when the data objects are written to, their content is undefined when the exception is handled. If the result set consists of one row, the columns of this row are assigned to the data objects. If the result set has multiple rows, the statements SELECT>> and WITH >> are used to open a SELECT> loop that itself must be closed using ENDSELECT>> or ENDWITH>>. A SELECT> loop assigns the columns of the result set to the data objects row by row and evaluates them. If used in the statement FETCH>>, the columns of the row are extracted at the current cursor position. Latest notes: If the result set is defined in the SELECT> list> by specifying *> or data_source~*>, it is not possible to specify a comma-separated list of data objects. The comma-separated list can span multiple program lines. NON_V5_HINTS ABAP_HINT_END ABAP_EXAMPLE_VX5 Reading of the three columns of a result set to three elementary data objects. The first data object carrid> is a previously declared host variable. The second data object carrname > is a host variable declared inline. The third data object is an anonymous data object created using NEW >> and to which a data reference variable dref> declared inline points. ABEXA 00359 ABAP_EXAMPLE_END ABAP_EXAMPLE_VX5 Reading of the four columns of a result set into four individually specified components of a structure. Unlike when writing to a work area using CORRESPONDING FIELDS> (see below), the runtime framework does not compare names here. ABEXA 00360 ABAP_EXAMPLE_END ABAP Alternative 2 ... INTO $[CORRESPONDING FIELDS OF$] wa> What does it do? Specifies a single work area wa>> as a target area of the INTO> clause. This can be specified for all result sets. The data object wa>> can be specified as an existing host variable> or declared inline using @DATA>> or @FINAL>>. The addition NEW>> allows the creation of an anonymous data object. If the result set consists of a single row, this row is assigned to the work area wa>. If the result set has multiple rows, the statements SELECT>> and WITH >> are used to open a SELECT> loop that itself must be closed using ENDSELECT>> or ENDWITH>>. A SELECT> loop assigns the result set to the work area wa> row by row and evaluates it. After ENDSELECT > or ENDWITH>, the work area wa> contains the row that was assigned last. If used in the FETCH>> statement, a row is extracted at the current cursor position. If the result is empty, the work area remains unchanged. If a catchable exception is raised when the work area is filled, its content is undefined when the exception is handled. If the optional addition CORRESPONDING FIELDS OF> is specified, wa> must be a structure>. This addition specifies that only the content of columns that have identically named components in wa> is assigned to them. If the addition CORRESPONDING FIELDS OF> is not specified, wa> must meet the prerequisites described under Work Areas in Statements>. The rows of the result set are assigned as follows, based on the definition of the result set in the SELECT> list>: Definition of the result set using *> without the addition CORRESPONDING FIELDS OF>> in the INTO> clause: If all columns of the data sources are read using *>, CORRESPONDING FIELDS> is not specified and the SELECT> statement is not the main query of a WITH>> statement, SELECT> behaves as follows: A work area without LOB handle components> is assigned the row of the result set, left-aligned and unconverted and in accordance with the structure of the result set. Unaffected parts of wa> retain their previous content. To be able to access the components of the result set according to type after the assignment, the work area wa> must be structured like the result set. When an LOB handle structure> is specified, it must be constructed exactly like the structure of the data source>, in accordance with the prerequisites>. The content of the columns of the result set that are not assigned to any LOB handle components> are directly assigned to the corresponding components of the work area. One LOB handle> is created for each LOB handle component. All Other Combinations> If the result set consists of a single column specified explicitly after SELECT> or a single SQL expression > or a single aggregate expression>, wa> can be an elementary data object or a structure. If the result set consists of multiple columns, it must be a structure and the following rules apply: If the addition CORRESPONDING FIELDS> is not specified, wa> must contain enough components and the content of the columns are assigned to the components of wa> from left to right in the order specified after SELECT>. The content of surplus components of wa> is not changed. If the addition CORRESPONDING FIELDS> is specified, only those content of columns for which there are identically named components in wa> are assigned to them. The alias names defined using