Get Example source ABAP code based on a different SAP table
AB_SQL - Work Areas in Statements If any of the AB-SQL statements listed below specify work areas wa > or internal tables itab> as the target or source areas, the following prerequisites apply to the work area or row type of the internal table.
SELECT> or FETCH> without the addition CORRESPONDING FIELDS>,
INSERT>, UPDATE>, MODIFY>, or DELETE> If these prerequisites are ignored, a syntax error occurs or an exception is raised. ITOC
Regular Work Areas The following rules apply to work areas BEGIN_SECTION VERSION 5 OUT that do not contain reference variables for LOB handles> END_SECTION VERSION 5 OUT :
The data type of the work area or row type of the internal table must not be deep> or contain deep components. This excludes strings and special work areas for streaming> and locators >.
The data type of the work area and the row type of the internal table must not contain any enumerated types >.
The work area or row type of the internal table must be at least as long as the database structure and the alignment> must match. In the statement DELETE>, this prerequisite must only be met in the length of the primary key>.
If the work area or rows of the internal table are structured, the fragment view> of the database structure must match that of the work area or the internal table.
If the work area or rows of the internal table are elementary, they must be character-like and flat>. The columns of the database structure must also be character-like and flat.
If the work area contains strings as components or is itself a string, or if columns of type SSTRING>>, STRING>>, RAWSTRING>>, or GEOM_EWKB> appear in the database structure, the work area must be compatible with the database structure.
If the column specification *> is used in the statement SELECT > to access a CDS entity>, the work area is always checked as if it contained a string as a component.
For the modifying operations INSERT>, UPDATE>, and MODIFY>, the passed values must match the value range of the columns of the DDIC database tables. Otherwise, corresponding exceptions are raised. This applies in particular to the following:
Columns with numeric data types.
Columns of the types SSTRING>, STRING>, RAWSTRING> , or GEOM_EWKB>. The strings of the work area must not be longer than the maximum length of the columns in the database structure. This length can be determined using the built-in function dbmaxlen>>.
Columns of the types DATN>, TIMN>, and UTCLONG>. Only valid dates, times, and time stamps can be passed.
Latest notes: The work area or row structure of the internal table should always be structured in the same way as the database structure. If a single data source is used in the AB-SQL statement, a data object built in the same way can be declared with reference to the relevant DDIC structure. If multiple data sources are used (in the statement SELECT>), a data object built in the same way can be constructed as a nested structure, which contains the structures of the single data sources in the order specified in the statement as substructures. No structure should be used in which all components are on one level, because this ignores potential alignment gaps> between the individual data sources. NON_V5_HINTS ABAP_HINT_END BEGIN_SECTION VERSION 5 OUT
LOB Handle Structures If a work area is an LOB handle structure>, that is, it contains at least one reference variable for LOB handles>, it must be structured in exactly the same way as the structure of the data source and all components except for the LOB handle components> must be compatible> with the corresponding components of the data source. The static type of each LOB handle component must contain the IF_ABAP_DB_LOB_HANDLE> interface and match both the current statement and the data type of the assigned LOB.
Latest notes: In the statement FETCH>, no LOB handle structures can currently be specified. NON_V5_HINTS ABAP_HINT_END END_SECTION VERSION 5 OUT