Anda di halaman 1dari 2


Purpose of the Check

Buffered table in a JOIN

JOINs bypass the SAP table buffer. Buffered tables should be accessed using the simplest SELECT
statements possible so as not to risk bypassing the buffer.

If one of the tables in a JOIN is buffered, it is best to first import the required entries using a SELECT into an
internal table itab, and then (for example, using the statement SELECT ... FOR ALL ENTRIES IN
itab) access the further tables. This naturally applies only if the buffered table can be accessed using the
SAP table buffer.

Click the link to find out what you can do.

This message can be hidden using the pseudo comment "#EC CI_BUFFJOIN

SELECT statements that bypass the SAP table buffer


You should proceed as follows whenever a SELECT statement on a buffered table bypasses the SAP
table buffer.

Note that changes in the buffering settings can also affect other statements. The size of the SAP table buffers
is limited; some large tables with incorrect buffering settings can displace many small tables from the buffer.

 If the statement (form routine, function module, method, program, ...) is part of customizing, check
whether an explicit BYPASSING BUFFER should be added to the SELECT statement.Perhaps the
buffer was bypassed intentionally and this was specified implicitly until now. The set of statements that
bypass the buffer can however change in future development. If a bypass is wanted, this should be
formulated explicitly.

If not, select the SELECT statement with the required pseudo comment "#EC CI_....

 If the statement is used frequently in the production system, try to reformulate the WHERE condition
so that the SAP table buffer can be used.

Likewise, it can be of benefit to replace ABAP JOINs containing buffered tables by SELECT
statements in the individual tables. Even the SELECT additions DISTINCT and ORDER BY (the latter
means that the buffer is bypassed if the sort order does not match the primary key) can be processed
faster in buffered tables using ABAP methods. This naturally applies only if the SELECT statement
can use the SAP table buffer on the basis of the WHERE condition.

 Only as a last resort should you think of changing the buffering settings. Use the where-used list to
examine how the table is accessed in different ways. Perhaps the table should be buffered differently
(for example, using single-record buffering instead of generically) or not at all.
Purpose of the Check
SELECT statements that bypass the SAP table buffer

When reading data, SAP table buffering (the buffering of database tables on the application server) has a major
performance advantage over accessing the database. Buffer, therefore, any suitable tables and do not
bypass the buffer for buffered tables. The following can produce a bypass:

 Bypassing by design using SELECT ... FOR UPDATE and SELECT ... BYPASSING BUFFER

 Use in JOINs

 Use in subqueries

 Aggregate functions COUNT, MAX, MIN, SUM, AVG


 ... GROUP BY ...

 ... ORDER BY ... if the sort fields have a different order than in the primary key

 ... IS [NOT] NULL in the WHERE condition

 (Generic) key not specified in full when using generic or single record buffering

 Key not specified in full when using CLIENT SPECIFIED on a client-specific table without a client
field in the WHERE condition

What do I do if a SELECT statement bypasses the SAP table buffer?

This check does not report the bypassing of the table buffer when using Native SQL well as when using
constructs such as SELECT * FROM dbtab AS db WHERE db~field1 > db~field2 .

From SAP_BASIS 7.10, the keyword SINGLE is no longer necessary for (buffer) access to a single record
buffered table.