Skip to content

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

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 CREATING addition must be specified if a 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 result set after INTO:

  • IF_ABAP_DB_LOB_HANDLE
  • IF_ABAP_DB_BLOB_HANDLE
  • IF_ABAP_DB_BLOB_HANDLE

The specifications after CREATING determine the class from which the associated LOB handles are created. For all other possible static types, you can determine the class from the static type and the LOB type. The specification of CREATING is not allowed 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 column specifications for the derivation of LOB handle structures with TYPES. Unlike the TYPES statement, type specification is limited here to READER and LOCATOR, and only components that are typed with a LOB interface are respected. The type specification of the first two entries after CREATING must not 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 result 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 result 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.
  • When specified, ALL ... COLUMNS respects these columns only.

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

  • When specified, ALL ... COLUMNS also respects those columns that are added by later enhancements to the database tables or views.
  • 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, you can specify a data object crea_syntax in parentheses which contains the syntax of the static additions or is initial when executing the statement. For crea_syntax, the same applies as for column_syntax when specifying columns dynamically after SELECT. If the content of crea_syntax is initial, the CREATING addition is ignored.