Skip to content

ABAP Keyword Documentation →  ABAP - Reference →  Processing External Data →  ABAP Database Accesses →  Open SQL →  Open SQL - Read Accesses →  SELECT →  SELECT - INTO 

SELECT - CREATING

Short Reference

Other versions: 7.31 | 7.40 | 7.54

Syntax


... CREATING {  READER|LOCATOR FOR { COLUMNS blob1 blob2 ... clob1 clob2 ... } 
                                 | { ALL [OTHER] [BLOB|CLOB] COLUMNS }
               [READER|LOCATOR FOR ...] }

           | {  (crea_syntax) }  ...

Extras

1. ... READER|LOCATOR

2. ... [ALL [OTHER] [BLOB|CLOB]] COLUMNS [blob1 blob2 ... clob1 clob2 ...]

3. ... (crea_syntax)

Effect

The addition CREATING must be specified if a reference variable for a LOB handle whose static type is one of the following three LOB interfaces is assigned to a LOB from the results set after INTO:

  • IF_ABAP_DB_LOB_HANDLE
  • IF_ABAP_DB_BLOB_HANDLE
  • IF_ABAP_DB_BLOB_HANDLE

The information specified after CREATING determines the class from which the associated LOB handles are created. For all other possible static types, the class can be determined from the static type and the LOB type. CREATING cannot be specified in this case.

The CREATING addition can be specified either statically or dynamically. In the static variant, class and columns are determined using additions; in the dynamic variant, the syntax of the static variants is specified in crea_syntax.

The syntax and the rules for the additions after CREATING correspond to the type and columns specified for the derivation of LOB handle structures with TYPES. Unlike the statement TYPES, type specification is limited here to READER and LOCATOR, and only components that are typed with a LOB interface are respected. The types specified for the first two entries after CREATING cannot be the same.

Addition 1

... READER|LOCATOR

Effect

These additions determine the LOB handle class for each of the columns specified.

  • READER creates reader streams for all of the columns specified.
  • LOCATOR creates locators for all of the columns specified after these.

The assignment to the classes corresponds to the type specification for the derivation of a LOB handle structure, except that here it is the dynamic type that is determined and not the static type.

Addition 2

... [ALL [OTHER] [BLOB|CLOB]] COLUMNS [blob1 blob2 ... clob1 clob2 ...]

Effect

These additions assign the previous type specifications to the columns of the results set. The meaning of the additions corresponds to the column specification for the derivation of an LOB handle structure. The difference is that the set of columns used is made up exactly of those columns from the results set, which were assigned to a reference variable whose static type is an LOB interface:

  • Do not specify individual columns for which this is not the case.
  • Bei der Angabe von ALL ... COLUMNS werden nur solche Spalten berücksichtigt.

The combination options for column specifications with one another and with type specifications are the same as for TYPES. Specifically, the column specification ALL OTHER ... must be the last column specification.


Notes

  • Mit der Angabe von ALL ... COLUMNS werden auch Spalten berücksichtigt, die durch spätere Erweiterungen der Datenbanktabellen bzw. Views hinzukommen.
  • The actual names must be used for the column specifications blob1, blob2, clob1, clob2, and so on. The alternative column names are ignored.

Addition 3

... (crea_syntax)

Effect

As an alternative to static variants, a data object crea_syntax can be specified in parentheses which contains the syntax of the static additions or is initial when executing the statement. Für crea_syntax gilt das Gleiche wie für column_syntax bei der dynamischen Spaltenangabe in der SELECT-Liste. If the content of crea_syntax is initial, the addition CREATING is ignored.