Kontakt

Ansicht
Dokumentation

ABAPSELECT_LIST - SELECT LIST

ABAPSELECT_LIST - SELECT LIST

General Data in Customer Master   BAL_S_LOG - Application Log: Log header data  
This documentation is copyright by SAP AG.
SAP E-Book

SELECT, select_list

Short Reference



... *
  $| ${..., data_source~*, ..., col_spec $[AS alias$], ...$}
  $| (column_syntax) ...

Alternatives:

1. ... *

2. ..., data_source~*, ..., col_spec $[AS alias$], ...

3. ... (column_syntax)

Effect

SELECT list of the SELECT clause of a query. The specifications determine which columns are used to construct the result set of the SELECT statement and how their values are obtained. There are two static variants and one dynamic variant.

The SELECT list actually passed to the database is determined by the addition INTO CORRESPONDING. If one or more names match, all the columns for which there are no name matches are removed from the SELECT list implicitly and therefore from the result set as well. If there are no name matches, none of the columns are removed from the result set.

Alternative 1

... *


Effect

Defines all columns of the result set using *. The result set is constructed from all columns in the data sources specified after FROM, in the order specified there. The columns of the result set inherit their names and data types from the data sources. Only a single data object can be specified after INTO and lists of data objects cannot be specified.

Notes

  • If multiple DDIC database tables are specified after FROM, it is not possible to prevent multiple columns from inheriting the same name when * is specified.
  • For performance reasons, only those columns that are actually needed should be specified. * should only be specified if the content of all columns is actually needed.
  • If the addition INTO CORRESPONDING is used, * can be transformed implicitly to a list of columns for which there is a name match.

Example

Reading of all columns with multiple rows.

Alternative 2

..., data_source~*, ..., col_spec $[AS alias$], ...


Variants:

1. ... data_source~* ...

2. ... col_spec $[AS alias$] ...

Effect

Comma-separated list with

  • data_source~* specifying all columns of a data source data_source or
  • the definition of individual columns col_spec of the result set.

The individual specifications can be combined in any way, with the exception that data_source~* cannot be used together with aggregate expressions.

Note

When a comma-separated list is used, the syntax check is performed in a strict mode, which handles the statement more strictly than the regular syntax check. Specifying individual blank-separated columns is obsolete.



Variant 1

... data_source~* ...


Effect

Defines multiple columns of the result set using data_source~*, where data_source stands for an individual DDIC database table dbtab, a DDIC view view, a non-abstract CDS entity cds_entity, or an internal table. The result set contains all columns of the specified data source data_source at the relevant positions and in the order of the columns. The names of the database sources or their alias names can be specified for data_source that are also specified as data_source after FROM. A data source can also be specified more than once. If data_source~* is used, only a structure can be specified after INTO, no elementary data objects or lists of data objects.

The following special conditions should be noted:

  • When an internal table @itab with elementary row type is accessed in the FROM clause of a common table expression after WITH, data_source~* cannot be specified in the SELECT list.

Notes

  • For performance reasons, only those columns that are actually needed should be specified. data_source~* should, therefore, only be specified if the content of all columns is actually needed.
  • The definition of the result set can also be produced by specifying a single data source data_source~*. This defines the same result set as specifying * but can be different if information is specified after INTO and the resulting behavior.
  • When data_source~* is used, the syntax check is performed in a strict mode, which handles the statement more strictly than the regular syntax check.

Example

Reading of the columns of two DDIC database tables in a join into an internal table. Two columns are read from SCARR and all columns are read from SPFLI.

Variant 2

... col_spec $[AS alias$] ...


Addition:

... AS alias

Effect

Definition of individual columns of the result set via specified columns col_spec, which can be defined using any SQL expressions. The order in which the columns are specified is arbitrary and defines the order of the columns in the result set. Only if a column of the type LCHR or LRAW is specified explicitly as col must the corresponding length field also be listed directly in front of it. Different specifications can be made after INTO, the interaction of which is described by the column specified there.

Notes

  • The obsolete short form without an explicitly specified target area cannot be used when specifying individual columns. The only exception here is when the aggregation function count( * ) is used to statically specify nothing, if no alias name and no GROUP BY are specified.
  • Instead of using commas, blanks can be used to separate columns specified in an obsolete form. Commas must be specified, however, in the strict modes of the syntax check from Release .

Example

Reading of two columns from a cell in the DDIC database table SCARR.

Addition

... AS alias

Effect

The addition AS can be used to define an alias name alias with a maximum of thirty characters in the result set for every specified column col_spec. The alias name alias must follow the naming conventions for internal program names and the name table_line cannot be used. This is checked in strict mode of the syntax check from Release .

An alias name cannot be assigned more than once and should not be the name of a column that does not have any alias names assigned to it. The alias name is used implicitly in the addition INTO$|APPENDING CORRESPONDING FIELDS OF. An alias name can only be specified after ORDER BY. A non-unique column name used after ORDER BY causes a syntax error or an exception.

Notes

  • If multiple DDIC database tables are specified after FROM, alternative names can be used when specifying single columns to avoid having multiple columns with the same name.
  • In particular, an alias name cannot be used as the operand of an SQL expression.
  • If an alias name is to be named exactly like an addition of the SELECT statement, it may be necessary to prefix it with the escape character !.
  • Outside of the strict syntax check mode from Release , it is also possible for an alias name to contain the minus sign (-), which allows assignments to be made to components of substructures with the addition CORRESPONDING FIELDS OF in the INTO clause.

Example

Display of the flight date and average fare of all customers on Lufthansa flights with flight number 0400. The alternative name avg of the aggregate expression is required for the ORDER BY clause and the inline declaration using @DATA(...) in the INTO clauses.

Alternative 3

... (column_syntax)


Effect

Instead of the previous two static specifications, a data object column_syntax in parentheses can be specified. When the statement is executed, this data object either contains the syntax shown in static cases with the exception of host expressions or is initial.

The data object column_syntax can be a character-like data object or a standard table with a character-like row type. The syntax in column_syntax is not case-sensitive, as in the static syntax. When an internal table is specified, the syntax can be distributed across multiple rows.

If column_syntax is initial when the statement is executed, select_list is set implicitly to * and all columns are read.

If columns are specified dynamically without the addition SINGLE, the result set is always regarded as having multiple rows.

Invalid syntax raises a catchable exception from the class CX_SY_DYNAMIC_OSQL_ERROR. See SQL Injections Using Dynamic Tokens.

Notes

  • If column_syntax is an internal table with a header line, the table body is evaluated, and not the header line.
  • The class CL_ABAP_DYN_PRG contains methods that support the creation of correct and secure dynamic column specifications.
  • In dynamically specified columns, static attributes or constants of a class cannot be accessed from outside in cases where the class has a static constructor and the constructor has not yet been executed.

Example

All departure or destination cities of Lufthansa flights are produced, depending on whether 'CITYFROM' or 'CITYTO' is specified. A method of the class CL_ABAP_DYN_PRG is used to check whether the input values are valid.

Example

Comment character in a dynamically specified token. The rows introduced using * and the content from the character " are ignored.

Remove Columns from the SELECT List.






SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up   ABAP Short Reference  
This documentation is copyright by SAP AG.

Length: 16869 Date: 20240419 Time: 080651     sap01-206 ( 226 ms )