Accesses Proceeding Directly to the Database 

When you program accesses to buffered tables, you must know which accesses read from the buffer and which accesses go directly to the database.

The following accesses always bypass the buffer and proceed directly to the database:

●      SELECT... BYPASSING BUFFER

●      SELECT FOR UPDATE

●      SELECT with aggregate function, for example COUNT, MIN, MAX, SUM, AVG

●      SELECT DISTINCT

●      SELECT... WHERE... IS NULL

●      SELECT with GROUP BY or HAVING clause

●      SELECT with subqueries or joins

●      ORDER BY (with the exception of PRIMARY KEY)

With generic buffering, all SELECT statements that do not fully specify the generic key also proceed directly to the database. With generic buffering, the buffer can only be used for accesses that specify the complete generic key.

With single-record buffering, each SELECT statement that does not specify the complete key proceeds directly to the database.

All accesses with Native SQL (EXEC SQL) bypass the buffer and proceed directly to the database. Such accesses must be avoided at all costs with buffered tables. First of all, read accesses always bypass the table buffers. Secondly, the SAP system does not notice modifying accesses since no entries are made in the synchronization table here (for more information, see Synchronization of Local Buffers). This can lead to inconsistencies between the data in the buffers of the application server and the database.