SAP ABAP SQL CLIENT HANDLING



Get Example source ABAP code based on a different SAP table
  



AB_SQL - Client Handling
The term client handling means the handling of the application data of a client. The aim of client handling is generally that an ABAP user can only have access to the application data of the client whose client ID was specified in the logon. AB_SQL uses implicit client handling. This method of client handling has the effect that AB-SQL statements handle the client column in a special way when client-dependent data sources are accessed:
The client column cannot be evaluated in the SQL conditions of the SELECT statements of queries and of the write statements UPDATE SET and DELETE FROM.
Instead, the SQL statements passed to the database by the ABAP SQL interface contain an additional condition for the client column.
Furthermore, joins between client-dependent data sources insert an ON condition that checks the client columns for equality.
The variants of the write statements INSERT , UPDATE, MODIFY , and DELETE, which use data from work areas, internal tables, or subqueries specified after FROM, ignore their client columns and the value is set by AB_SQL instead.
Implicit client handling uses the client ID of the current client by default. This ID is also contained in the system field sy-mandt.
The condition passed implicitly in selections checks the content of the client column for equality with the client ID of the current client.
In write statements, AB_SQL uses the client ID of the current client for the client column of the target instead of the values of the client column of the work areas, internal tables, or subqueries specified after FROM.
This means that AB_SQL uses only the data of the current data by default and this does not need to be specified explicitly by the developer.
BEGIN_SECTION VERSION 5 OUT Implicit client handling can, however, also be switched from the default current client to other clients using additions of the AB-SQL statements. The cases described above must also be distinguished here:
The implicit condition of queries and the write statements UPDATE SET and DELETE FROM can be switched from the current client to other clients as follows:
The addition USING CLIENT of the SELECT statement and the addition USING CLIENT of the write statements are used to specify the client ID from the addition instead of the current client ID. Implicit client handling works as if the current user was logged on with the specified client ID.
The additions USING $[ALL$] CLIENTS $[IN$] of the SELECT statement and USING $[ALL$] CLIENTS $[IN$] of the write statements are used to replace or remove the equality condition for a client with different conditions for multiple clients. The condition is then non-unique instead of unique. In both cases, the joins of queries preserve the additional implicit ON condition.
The value set implicitly for the client column of the work areas, internal tables, or subqueries specified after FROM in write statements can be switched from the current client to other clients as follows:
AB_SQL uses the addition USING CLIENT to specify the client ID from the addition instead of the current ID. Implicit client handling works as if the current user is logged on with the specified client ID.
If AB_SQL specifies the addition CLIENT SPECIFIED, no replacement takes place. The values of the client column of the work areas, internal tables, or subqueries specified after FROM are used. In internal tables and subqueries, there may be multiple client IDs.
In addition to the case described above, the addition CLIENT SPECIFIED can also be used instead of USING in the other cases for modifying statements with data sources after FROM. This use is obsolete in queries and obsolete in the write statements UPDATE SET and DELETE FROM. The addition CLIENT SPECIFIED completely deactivates implicit client handling in these statements. This means that no implicit WHERE condition is created for the client column and no ON condition is created between the client columns in joins. The client column in the SQL conditions of the AB-SQL statements, on the other hand, can or must itself be evaluated. Deactivating implicit client handling in this way is prone to errors and hence not recommended. The USING additions for switching implicit handling should be used instead.
END_SECTION VERSION 5 OUT

ABAP_PGL
Client Handling
ABAP_PGL_END



Latest notes:
The implicit client handling of ABAP SQL does not concern the INTO clause and the rules described there. In particular, the client column of a target structure can be filled with other values than the client ID, for example when assigning individually specified columns of a select list.
For information about accessing client-dependent CDS entities, see the following descriptions:
Client Handling in CDS View Entities
Client Handling in CDS DDIC-Based Views
Client Handling in CDS Table Functions .
The DDIC database table T000 contains the potential client IDs in AS ABAP. Client columns of application tables should contain only those client IDs specified in T000. This is not, however, checked by AB_SQL .
Native SQL and AMDP do not implement implicit client handling. The current client must always be specified explicitly here.
The client data from an AS ABAP is represented in self-contained units. No client-independent access to databases should take place in application programs.
NON_V5_HINTS
This is why the additions USING and CLIENT SPECIFIED should never be used here. If AB_SQL is used, there is generally no need to access sy-mandt in application programs either.
True multitenancy, with which the system ensures that different tenants' application data is isolated from each other, is not supported by the ABAP runtime framework in the current release.
ABAP_HINT_END