Entering content frameBackground documentation Single-Record Buffering Locate the document in its SAP Library structure

With single-record buffering, only the records that are actually read are loaded into the buffer. Single-record buffering therefore requires less storage space in the buffer than generic and full buffering. The administrative costs in the buffer, however, are greater than for generic or full buffering. Considerably more database accesses are necessary to load the records than for the other buffering types.

Example

In this example, the record highlighted in red is read by a program from table SCOUNTER. If single-record buffering is selected for the table, only the record that was read is loaded into the buffer.

This graphic is explained in the accompanying text

When Should you Use Single-Record Buffering?

Single-record buffering should be used particularly for large tables where only a few records are accessed with SELECT SINGLE. The size of the records being accessed should be between 100 and 200 KB.

Full buffering is usually more suitable for smaller tables that are accessed frequently. This is because only one database access is necessary to load such a table with full buffering, whereas several database accesses are necessary for single-record buffering.

Access to Buffered Data

All accesses that are not submitted with SELECT SINGLE go directly to the database, bypassing the buffer. This applies even if the complete key is specified in the SELECT statement.

If you access a record which is not yet buffered with SELECT SINGLE, there is a database access to load the record. This record is marked in the buffer as non-existent if the table does not contain a record with the specified key. This prevents another database access when accessing the table at a later time with the same key.

 

 

Leaving content frame