When programming accesses to buffered tables it is important to know which accesses read from the buffer and which accesses go directly to the database.

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

• SELECT... BYPASSING BUFFER

• SELECT FOR UPDATE

• SELECT with aggregate function (COUNT, MIN, MAX, SUM, AVG)

• SELECT DISTINCT

• SELECT... WHERE... IS NULL

• ORDER BY (with the exception of PRIMARY KEY)

Depending on the buffering type chosen, other accesses may also proceed straight to the database, bypassing the buffer.

In generic buffering all SELECT statements which do not fully specify the generic key proceed straight to the database. Therefore, with generic buffering the buffer can only be used for accesses which specify the complete generic key.

In single-record buffering each SELECT statement without the suffix SINGLE proceeds straight to the database, even if the complete key is specified in the SELECT statement. In single-record buffering, therefore, the buffer can be used only for accesses with SELECT SINGLE.

Of course, all accesses with Native SQL (EXEC SQL) also bypass the buffer and proceed straight to the database. Such accesses should be avoided at all costs with buffered tables. First, read accesses always bypass the table buffers, and second, the R/3 System does not notice change accesses (as no entries are made in the synchronization table). This can lead to inconsistencies between the data in the buffers of the application server and the database.