SAP BUFFER RESTRICTIONS



Get Example source ABAP code based on a different SAP table
  



ABAP_BUFFER - Restrictions
Only transparent tables can be buffered. Global temporary tables cannot be buffered. There is no special restriction on the key length of the table when buffering, which means that keys in buffered tables can be up to 900 bytes long. For database accesses using
BEGIN_SECTION VERSION 5 OUT Native SQL and
END_SECTION VERSION 5 OUT AMDP, the table buffer is not used in principle.
Any writes access the data in the database table directly and trigger asynchronous buffer synchronization. After the invalidation of an entry in the buffer using a write statement, the next five reads that should have accessed the entry bypass the buffer of the current ABAP_ASINSTANCE by default. The next read performed on the changed entry reloads it into the buffer and removes the invalidation.
BEGIN_SECTION VERSION 5 OUT The number of reads that bypass the buffer before the reload is specified in the profile parameter zcsa/sync_reload_c.
END_SECTION VERSION 5 OUT
The fact that certain operations can only be performed on the database and not in the table buffer produces the further restrictions for reads listed below. If these restrictions are not respected, read AB-SQL statements bypass the table buffer implicitly and access the DDIC database tables, DDIC views or CDS view entities directly.
The following reads always bypass the table buffer:
Use of subqueries, and thus in particular the statement WITH.
The AB-SQL language element GROUPING SETS.
The AB-SQL set operators UNION, INTERSECT, and EXCEPT.
Reads on a table or view for which a replacement object is defined.
Reads using a database connection specified explicitly using the addition CONNECTION. This also applies when the standard connection is specified explicitly.
Reads redirected using the class CL_OSQL_REPLACE during a unit test.
Reads on a ABAP_CDS_V1_VIEW that does not meet the prerequisites for buffering.
The following applies in a main query:
No aggregate expressions can be used in the SELECT list.
Only specific SQL expressions can be used.
The additions DISTINCT and FOR UPDATE cannot be used.
No JOIN expressions can be specified.
The GROUP BY clause cannot be used. This also excludes the HAVING clause.
The ORDER BY clause cannot be used in cases where single columns are specified as sort keys and these columns are not a left-aligned subset of the primary key in the correct order or if the addition DESCENDING is specified in a column.
BEGIN_SECTION VERSION 5 OUT
The obsolete addition CLIENT SPECIFIED can be specified to disable implicit client handling in client-dependent data sources only if their client column is specified in a WHERE condition.
END_SECTION VERSION 5 OUT
Restrictions on the SQL condition in the WHERE clause:
When a table or view with single record buffering is accessed, all key fields of the primary key must be listed using equality conditions joined using AND.
When a generically buffered area is accessed, it must be specified completely using equality conditions joined using AND.
Only specific SQL expressions can be used on the left side of a relational expression.
Only host variables or host expressions can be used on the right side of a relational expression that is used to identify a single record or a generically buffered area. In any other relational expressions of a condition, columns can also be specified in comparisons or when BETWEEN is used. This applies in cases where neither numeric operand has the type DF16_DEC or DF34_DEC, both operands are character-like, or both operands have the type RAW with the same length.
No column can be compared with another column in a data source specified after FROM.
If FOR ALL ENTRIES is used when accessing a table or view with generic buffering, the generic area must be specified exactly, and multiple generic areas cannot be joined using OR.
The variant of the operator IN with an operand list on the left side cannot be used.



Latest notes:

For performance reasons, the fact that the table buffer is bypassed when these restrictions are not met should always be remembered when accessing buffered tables or views.
To bypass the table buffer in the statement SELECT explicitly, the addition BYPASSING BUFFER should always be used. It is not enough to rely on the implicit behavior itself.
The prerequisites for table buffering of CDS view entities are checked as restrictions for the view itself. If a CDS view entity can be enabled for table buffering and buffering is switched on with a CDS entity buffer , there should be no reason for ABAP SQL to bypass the buffer.
In cases where an internal table is used as a data source of a query, the read restrictions also determine whether the table can be evaluated on the AS ABAP or whether its content needs to be transported to the database.
NON_V5_HINTS
ABAP_HINT_END
BEGIN_SECTION SAP_INTERNAL_HINT
Note 1376858, isolation level, only for old buffer!
END_SECTION SAP_INTERNAL_HINT

BEGIN_SECTION SAP_INTERNAL_HINT
cl_osql_debug=>toggle_debug_mode( ).
abap sql statement.
cl_demo_output=>display( cl_osql_debug=>cursor_type[ 1 ] ).
END_SECTION SAP_INTERNAL_HINT