Get Example source ABAP code based on a different SAP table
ARTICLE
Open SQL - SAP Buffering When accessing a database table using Open SQL, SAP buffering is usually active if it is defined for the database table in question. The definition of a database table in ABAP Dictionary determines whether and how it is buffered. There are three buffering types:
Individual record buffering or partial buffering of individual records
Generic buffering of specific areas
Complete buffering of the whole table With the exception of the statements listed below, read Open SQL statements access the buffer. Modifying Open SQL statements that make modifications using work areas access the buffer of the current application server directly and invalidate the entries affected in the buffer of the other application server. Modifications using UPDATE ... SET ... WHERE ... or DELETE ... WHERE ... invalidate the entries affected in the buffers of all the application servers. The invalidation of the entries on the other application servers does not happen directly and uses a buffer synchronization that is called periodically. The time interval can be set using the profile parameter rdisp/bufreftime and has a default value of two minutes. An access to an invalidated entry of a buffer reloads the entry from the database. You can use the addition BYPASSING BUFFER of the SELECT statement to switch off access to the buffer explicitly. As well as specifying the BYPASSING BUFFER explicitly, SAP buffering is also avoided implicitly by some variants of Open SQL statements since the corresponding operations can only be carried out in the database and not in the SAP buffer. The following Open SQL statements avoid SAP buffering implicitly and access the database table directly:
SELECT with the addition FOR UPDATE.
SELECT with the addition DISTINCT,
SELECT with aggregate expressions.
Open SQL statement with the addition CLIENT SPECIFIED when the client ID is not specified in a WHERE condition.
SELECT with JOIN expressions.
SELECT, if the WHERE condition compares a column with another column from a database table specified after FROM.
Access to a table with individual record buffering without specifying (in the WHERE condition) all the equality conditions joined by AND for all the key fields of the primary key.
Access to a generically buffered area without complete specification of equality conditions joined by AND in a WHERE condition.
Open SQL statements with IS [NOT] NULL in the additions WHERE and HAVING.
Use of a subquery in a WHERE condition.
SELECT with FOR ALL ENTRIES in the following cases:
Access to a table with single record buffering.
Access to a table with generic buffering if the requirement to specify the generic area exactly (as specified above) is violated. The condition after FOR ALL ENTRIES cannot produce an OR relationship between multiple generic areas.
SELECT with the addition GROUP BY ,
SELECT with the addition ORDER BY , if individual columns are specified as the sort key, and these columns are not a left-aligned subset of the primary key in the correct order.
After the invalidation of an entry in the buffer using a modifying statement, the next five read accesses that should have accessed the entry avoid the buffer of the current application server by default. The next read access to the changed entry reloads it into the buffer and removes the invalidation. The number of read accesses that avoid the buffer before the reload is specified in the profile parameter zcsa/sync_reload_c. INTHINT All Open SQL statements that are executed in the same INTHINT LUW after calling function module DB_SET_ISOLATION_LEVEL INTHINT do not use the SAP Buffer, see note 1376858.
Note The avoidance of the SAP buffer using the additions above should be noted for access to buffered data for performance reasons. To explicitly avoid the SAP buffer in the SELECT statement you should always use the BYPASSING BUFFER addition and not rely on the implicit behaviour of the additions above.
