Skip to content

ABAP Keyword Documentation →  ABAP − Reference →  Obsolete Language Elements →  Obsolete Processing of External Data →  Obsolete Database Access →  Obsolete ABAP SQL →  Obsolete Syntax in ABAP SQL 

SELECT - CLIENT SPECIFIED

Quick Reference

Other versions: 7.31 | 7.40 | 7.54

Obsolete Syntax

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

Extras

1. ... [entity1~clnt] [, entity2~clnt] ...

2. ... (clnt_syntax)

Effect

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 strict mode from Release 7.54 and whenever global temporary tables are accessed. The addition USING should be used instead of CLIENT SPECIFIED.

The addition CLIENT SPECIFIED disables implicit ABAP 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-specific data sources in question. Instead, the client column of client-specific 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 viewed 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 used in the subqueries of conditions sql_cond to specify the same client handling as in the main query.

If CLIENT SPECIFIED is specified for a client-specific CDS entity, the client field is read from the database and added to the results set. The structure of a client-specific CDS view or a client-specific CDS table function does not have a component for the client field, which means that a client column is added to the results set here implicitly. If the client field is accessed explicitly or implicitly in the SELECT statement, an addition entity~clnt must be used to give the field a name that can be used in the current statement.

If known statically that the data sources data_source are not client-specific, the addition CLIENT SPECIFIED must be specified. Furthermore, the addition CLIENT SPECIFIED cannot be used when the following CDS entities are accessed:

  • If the addition CLIENT SPECIFIED is used to access a CDS entity associated 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:


Notes

  • If data has to be accessed in a different client, CLIENT SPECIFIED is replaced by USING, since all necessary conditions are set implicitly and accessing client-specific CDS entities is more simple.
  • The fact that the addition CLIENT SPECIFIED disables automatic client handling and the addition USING switches automatic client handling is a distinction that is particularly significant when accessing client-specific CDS entities. Here, CLIENT SPECIFIED modifies the structure of the results 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-specific tables.
  • If the addition CLIENT SPECIFIED is specified, but the client ID in the WHERE condition is not, 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-specific 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.
  • In obsolete accesses on a CDS view under the name of its CDS database view, this view is handled like any classic view. The existence of a client column is the only relevant aspect for client dependence and the addition CLIENT SPECIFIED disables implicit handling of this column automatically. The structure type and the results set of the CDS database view of a client-specific CDS view always have a client column. If the obsolete annotation @ClientDependent:false is used, the CDS database view of a cross-client CDS view can, however, also be client-specific because the SELECT list of the view has a client column.
  • The addition CLIENT SPECIFIED is only forbidden for access to CDS views with the annotation @ClientHandling.algorithm:#SESSION_VARIABLE if the session variable $session.client is actually in use in the view in question. This is only the case here if client-specific database tables are accessed or if client-specific data sources are joined with cross-client data sources in outer joins.
  • CDS access control does not work for cross-client access. For this reason, the addition CLIENT SPECIFIED can only be used in access 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 cross-client data sources, the addition CLIENT SPECIFIED produces a syntax error in the strict modes of the syntax check from Release 7.40, SP05 or else a syntax warning.
  • See also the associated security note and the programming guideline.


Example

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

SELECT * 
       FROM scustom CLIENT SPECIFIED 
       WHERE mandt = '800' 
       INTO TABLE @DATA(customers).

Example

Accesses a client-specific CDS view with the addition CLIENT SPECIFIED. To do this, the row 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.

TYPES scarr_spfli_clnt TYPE demo_cds_scarr_spfli CLIENT SPECIFIED clnt. 

DATA scarr_spfli_clnt TYPE TABLE OF scarr_spfli_clnt WITH EMPTY KEY. 

SELECT * 
       FROM demo_cds_scarr_spfli CLIENT SPECIFIED 
       INTO TABLE @scarr_spfli_clnt.

The following example shows how the recommended addition USING ALL CLIENTS is used, for which no special target area is required.

DATA scarr_spfli TYPE TABLE OF demo_cds_scarr_spfli WITH EMPTY KEY. 

SELECT * 
       FROM demo_cds_scarr_spfli USING ALL CLIENTS 
       INTO TABLE @scarr_spfli.

Addition 1

... [entity1~clnt] [, entity2~clnt] ...

Effect

Declares the names clnt of the client fields of the client-specific CDS entities. If CLIENT SPECIFIED is used, the result set for a client-specific CDS entity has a client field, although the structure of the entity does not have components of this type. The declaration of a name with entity~clnt is required 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(...) 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-specific 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.


Note

A name defined with entity~clnt has absolutely no dependency on 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.


Example

Similar to 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.

TYPES scarr_spfli_clnt TYPE demo_cds_scarr_spfli CLIENT SPECIFIED clnt. 

DATA scarr_spfli_clnt TYPE TABLE OF scarr_spfli_clnt WITH EMPTY KEY. 

SELECT * 
       FROM demo_cds_scarr_spfli 
           CLIENT SPECIFIED demo_cds_scarr_spfli~client 
       WHERE client = '800' 
       INTO TABLE @scarr_spfli_clnt.

Executable Example

CDS Views, Client Handling

Addition 2

... (clnt_syntax)

Effect

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 row 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

As in the previous example for accessing a CDS view using the addition CLIENT SPECIFIED, but dynamic.

TYPES scarr_spfli_clnt TYPE demo_cds_scarr_spfli CLIENT SPECIFIED clnt. 

DATA scarr_spfli_clnt TYPE TABLE OF scarr_spfli_clnt WITH EMPTY KEY. 

DATA(source) = `demo_cds_scarr_spfli`. 
DATA(client) = `client`. 

DATA(clnt_syntax) = source && `~` && client. 
DATA(cond) = client && ` = '800'`. 

SELECT * 
       FROM (source) 
            CLIENT SPECIFIED (clnt_syntax) 
       WHERE (cond) 
       INTO TABLE @scarr_spfli_clnt.