ABAPSELECT_CLIENT_OBSOLETE - SELECT CLIENT OBSOLETE

ROGBILLS - Synchronize billing plans   BAL Application Log Documentation  
This documentation is copyright by SAP AG.

SELECT, CLIENT SPECIFIED

Short Reference

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

Additions

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 and whenever global temporary tables are accessed. Moreover, the addition CLIENT SPECIFIED is not allowed when accessing (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 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 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.

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

• CDS view entities or that use the session variable client.

• 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.
  
  

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.

• In obsolete accesses on a CDS view using the name of its CDS-managed DDIC 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 CDS-managed DDIC view of a client-dependent CDS view always have a client column. If the obsolete annotation @ClientDependent:false is used, the CDS-managed DDIC view of a client-independent 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 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.

• 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 Release 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-dependent database table, but needs an explicit WHERE condition to do this.

Example

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.

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

Addition 1

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

Effect

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.

Note

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.

Example

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.

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

Like in the previous example for accessing a CDS view using the additionCLIENT SPECIFIED, but with dynamic specifications.

SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up   Addresses (Business Address Services)  
This documentation is copyright by SAP AG.

Length: 17837 Date: 20230322 Time: 104052     sap01-206 ( 256 ms )