Skip to content

ABAP Keyword Documentation →  ABAP − Reference →  Processing External Data →  ABAP Database Access →  ABAP SQL 

ABAP SQL - Work Areas in Statements

If the ABAP SQL statements

  • SELECT or FETCH without the addition CORRESPONDING FIELDS,
  • INSERT, UPDATE, MODIFY, or DELETE

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; if the prerequisites are ignored, a syntax error occurs or an exception is raised.

Other versions: 7.31 | 7.40 | 7.54

Regular Work Areas

The following rules apply to work areas that do not contain reference variables for LOB Handles :

  • 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 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.


Note

The work area or row structure of the internal table should always be built like the database structure. If a single data source is used in the ABAP SQL statement, a data object built in the same way can be declared with reference to the relevant structure in ABAP Dictionary. If more than one data source is used (in the statement SELECT), a data object built in the same way can be built as a nested structure, which contains, as substructures, the structures of the single data sources in the order specified in the statement. No structure should be used in which all components are on one level, because this ignores potential alignment gaps between the single data sources.

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 exactly like 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.


Note

In the statement FETCH, no LOB handle structures can currently be specified.