SAP SELECT CLIENT - Obsolete ABAP Statements

Get Example source ABAP code based on a different SAP table
  ABAP Statement

VERSION 5 OUT
ID SELECT-CLIENT-SPECIFIED
• CLIENT SPECIFIED SELECT FROM (obsolete)

SELECT, CLIENT SPECIFIED
Short Reference

ABAP_SYNTAX_OBS
... CLIENT SPECIFIED ${ $[entity1~clnt$] $[, entity2~clnt$] ... $}
$| $[(clnt_syntax)$] ...

ABAP Addition
1 ... $[entity1~clnt$] $[, entity2~clnt$] ...
2 ... (clnt_syntax)

What does it do?
Generally, the addition CLIENT SPECIFIED can be specified in the statement SELECT of queries in the same places as USING. This is obsolete and forbidden in ABAP_STRICT_777 strict mode from ABAP_RELEASE ABAP_777 / and whenever global temporary tables are accessed. Moreover, the addition CLIENT SPECIFIED is not allowed when accessing ABAP_CDS_V2_VIEWS (for more details, see ABAP CDS - Client Handling in CDS View Entities). The addition USING should be used instead of CLIENT SPECIFIED.
The addition CLIENT SPECIFIED disables implicit AB_SQL client handling for the current query. No implicit condition is created for the current client and, in the case of joins, no equality condition is created for the client columns of the client-dependent data sources involved. Instead, the client column of client-dependent data sources can be specified in the SQL conditions of the query used to select clients.
The addition CLIENT SPECIFIED is applied only to the current query. If multiple queries are used in a SELECT statement or WITH statement, client handling must be examined separately for each query. More specifically, client handling in a main query is disabled separately from client handling in the subqueries used there. Unlike USING, CLIENT SPECIFIED can also be specified in the subqueries of conditions sql_cond to achieve the same client handling as in the main query.
If CLIENT SPECIFIED is specified for a client-dependent CDS entity, the client field is read from the database and added to the result set. The structure of a client-dependent ABAP_CDS_V1_VIEW or a client-dependent CDS table function does not have a component for the client field, which means that a client column is added to the result set here implicitly. If the client field is accessed explicitly or implicitly in the SELECT statement, an addition entity~clnt must be used to assign the field a name that can be used in the current statement.
If known statically that the data sources data_source are not client-dependent, the addition CLIENT SPECIFIED must not be specified. Furthermore, the addition CLIENT SPECIFIED cannot be used when the following CDS entities are accessed:

CDS entities in which an input parameter is annotated with the annotation @Environment.systemField:#CLIENT.

ABAP_CDS_V1_VIEWS in which the view annotation @ClientHandling.algorithm:#SESSION_VARIABLE is specified and the session variable $session.client is evaluated implicitly.

ABAP_CDS_V1_VIEWS that use the session variable client.

CDS view entities, because the session variable $session.client is always evaluated implicitly.

CDS entities linked with a CDS role and that are subject to CDS access control:

If the addition CLIENT SPECIFIED is used to access a CDS entity defined without the annotation AccessControl.authorizationCheck:#NOT_ALLOWED and the addition WITH PRIVILEGED ACCESS is not used in the FROM clause, a syntax check error occurs.

If the addition CLIENT SPECIFIED is used to access a CDS entity linked with a CDS role and that is subject to CDS access control, an exception is raised.
The addition CLIENT SPECIFIED cannot be used together with the following path expressions:

Path expressions in any positions in which CDS associations and CTE associations occur whose association target is client-dependent.

Path expressions in the FROM clause in which CDS associations and CTE associations occur whose association source is client-dependent.



Latest notes:

If data is to be accessed in a different client, CLIENT SPECIFIED is replaced by USING , since all necessary conditions are set implicitly and accessing client-dependent CDS entities is more simple.

The fact that the addition CLIENT SPECIFIED disables implicit client handling and the addition USING switches it is a big difference that is particularly significant when accessing client-dependent CDS entities. Here, CLIENT SPECIFIED modifies the structure of the result set.

If the addition CLIENT SPECIFIED is specified, the client column is handled like any other column of a data source. If the client ID is then not specified in the WHERE condition, the selection is made across all clients. Similarly, an explicit comparison of the client columns must generally be made in the ON conditions of joins between client-dependent tables.

If the addition CLIENT SPECIFIED is specified without the client ID in the WHERE condition, the SELECT statement bypasses table buffering.

If the data source is specified dynamically after FROM, the addition CLIENT SPECIFIED in SELECT can always be specified. If no client-dependent tables or views are used, no exception is raised and the addition is ignored, except when entity~clnt is used to defined a static name for the client column of a CDS entity.

When implicit client handling is disabled for CDS entities, a suitable target area can be declared by using the addition CLIENT SPECIFIED (also obsolete) of the statement TYPES.

CDS access control does not work for client-independent access. For this reason, the addition CLIENT SPECIFIED can only be used in accesses to CDS entities for which access control is disabled using the annotation AccessControl.authorizationCheck:#NOT_ALLOWED or using the addition WITH PRIVILEGED ACCESS in the FROM clause.

If specified for client-independent data sources, the addition CLIENT SPECIFIED produces a syntax error in the strict modes of the syntax check from ABAP_RELEASE ABAP_740_SP05 or else a syntax warning.

See also the associated security note and the programming guideline.
NON_V5_HINTS

In obsolete accesses on a CDS view using the name of its ABAP_CDS_MNG_VIEW , this view is handled like a DDIC view. The existence of a client column is the only relevant aspect for client dependency and the addition CLIENT SPECIFIED disables implicit handling of this column. The structure type and the result set of the ABAP_CDS_MNG_VIEW of a client-dependent CDS view always have a client column. If the obsolete annotation @ClientDependent:false is used, the ABAP_CDS_MNG_VIEW of a client-independent ABAP_CDS_V1_VIEW can, however, also be client-dependent because the SELECT list of the view has a client column.

The addition CLIENT SPECIFIED is only forbidden for access to ABAP_CDS_V1_VIEWS with the annotation @ClientHandling.algorithm:#SESSION_VARIABLE if the session variable $session.client is actually used in the view in question. This is only the case here if client-dependent database tables are accessed or if client-dependent data sources are joined with client-independent data sources in outer joins.
ABAP_HINT_END



Example ABAP Coding

Like the example for USING CLIENT, this example reads all customers in client 800 from a client-dependent database table, but needs an explicit WHERE condition to do this.
ABEXA 00595
ABAP_EXAMPLE_END



Example ABAP Coding

Accesses a client-dependent CDS view with the addition CLIENT SPECIFIED. To do this, the line type of the internal table used as a target range is defined using the addition CLIENT SPECIFIED of the statement TYPES. If the addition CLIENT SPECIFIED of the statement TYPES is not used, the column clnt would not exist in the table scarr_spfli_clnt and could not be used as a target range.
ABEXA 00596
The following example shows how the recommended addition USING ALL CLIENTS is used, for which no special target area is required.
ABEXA 00597
ABAP_EXAMPLE_END

ABAP Addition

What does it do?
Declares the names clnt of the client fields of the client-dependent CDS entities. If CLIENT SPECIFIED is used, the result set for a client-dependent CDS entity has a client field, although the structure of the entity does not have a component of this type. The declaration of a name with entity~clnt is necessary when accessing this type of client field explicitly or implicitly in the SELECT statement:

Specifies the client field explicitly as a column name in a clause of the SELECT statement.

Implicit use in CORRESPONDING. If a name has not been declared for a client field, this field is ignored.

Implicit use in inline declarations using @DATA|@FINAL(...) after INTO. If a name is not declared for a client field, inline declarations are not possible.
Here entity is the name of a client-dependent CDS entity used as a data source and clnt is a freely definable unique name for its client column, which is valid throughout the current SELECT statement.



Latest notes:
A name defined with entity~clnt is completely independent of the actual name of a client column in a data source of a CDS entity. It is used, for example, in a WHERE condition or ON condition to select specific clients in a CDS entity.
ABAP_HINT_END



Example ABAP Coding

Like the previous example for accessing a CDS view with addition CLIENT SPECIFIED. In this case, a WHERE condition is specified for the client column. This requires a name to be defined after CLIENT SPECIFIED.
ABEXA 00598
ABAP_EXAMPLE_END

ABAP_EXAMPLE_ABEXA
CDS Views, Client Handling
ABAP_EXAMPLE_END

ABAP Addition

What does it do?
If (source_syntax) is specified dynamically after FROM, a parenthesized data object clnt_syntax can be specified instead of a static $[entity1~clnt$] $[, entity2~clnt$] ... This data object must contain the static syntax when the statement is executed. The data object clnt_syntax can be a character-like data object or a standard table with a character-like line type. The syntax in clnt_syntax is not case-sensitive, as in the static syntax. When an internal table is specified, the syntax can span multiple rows.



Example ABAP Coding

Like in the previous example for accessing a CDS view using the addition CLIENT SPECIFIED, but with dynamic specifications.
ABEXA 00599
ABAP_EXAMPLE_END

Return to menu