Does Single Record Buffering work if I do not use the full key?

Question

I have a standard table in ABAP, buffering is activated, type Single Records. Yet every SELECT goes to the DB.
The table has fields [MANDT, A, B], but the SELECTs use only MANDT and A. Could this be the reason why the buffer is bypassed?

Answer 1

As the documentation for table buffering says, "Single Record" buffering only works when you provide the full primary key.

When this is a table which is under your control and there are no other applications which might prefer a different buffering strategy, then you can change its buffering type to " Generic Area " and enter the number of key fields you want to be part of the buffering key (2, in this case). When the table is very small, you might even consider to enable "Full Buffering", which will load the whole table into the application server's memory as soon as a single row is requested.

Alternatively, when all your accesses to the table happen within the same session, then you could consider to build your own in-memory buffering on the ABAP level. If you need your own buffering across sessions, you could build a buffer using a shared memory class . But this will of course become problematic when there are write-operations to the table which are beyond your control or write-operations on other application servers.

Answer 2

TLDR:

Does Single Record Buffering work if I do not use the full key?

No

Explanation follows:

How can you "KNOW" what sap is doing. Ok the docu is normally very accurate assuming you check the correction version of the docu.

7.5.4 docu says

When using single record buffering, any ABAP SQL statements must respect the full primary key to prevent them from bypassing table buffering.

In otherwords, if a table "full key buffered", Any attempt to read without the full key goes to the DB. There is also another TRAP in older releases where projections ignore the buffer. Run a Test trace on Select fieldA from Table1 where full key. To verifiy the buffer is used. (explained below)

How to test what is actually happening.
Find a time when few are using the App server...
Have a window open with your test code. (Use Eclipse:) )
In another window have st05 open.

1. Reset the table buffer ( you are in dev system right! )
   /$TAB into the command field.

2. IN ST05 start a trace for SQL and buffer

3. Run your test program. which access records using different techniques. Or repeats an access to test the buffering. eg

   DATA: ls_t001 TYPE t001.
   select single * from t001 into ls_t001
   where bukrs = '0001'.
   select single * from t001 into ls_t001
   where bukrs = '0001'.
   select single butxt from t001 into ls_t001
   where bukrs = '0001'.

4. Stop trace and Display / Analyze trace You can filter the trace output to be show only the table in question

The Blue lines are Buffer accesses. The yellow lines are SQL db accesses.

He you can see how the single record access resulted in 57 records being read/ loaded. IE full or generic table buffering. Loaded all for my client.

CAREFUL: DONT BE tempted to use SE16 as your test tool.
It has a gotcha for people testing Buffering.
SE16 uses the select BYPASSING BUFFER statement

To complete this topic a look at AL12 is useful. You can now "look at" the various buffer contents. Dont forget other clients.... when analyzing