Single-Record Table Buffers 

Use

Individual records of tables with single-record buffering are managed in the single-record table buffer TABLP.

Technical Implementation and Buffer Access

The single-record table buffer contains a central administrative structure, a table directory and the data area. The system organizes the data area in frames of a fixed size (default value 4 KB).

The system sorts the table names alphabetically in the directory. The table entries are also stored sorted in the corresponding frames of the data area.

In a buffer access, a binary search is first used to find the entry in the table directory, followed by the corresponding frame and then the record searched for within the frame.

Frames can overflow in the data area if new data is inserted while adhering to the sort sequence. Such overflow frames have to be divided up and their administrative structure must be updated. This explains why the single-record table buffer is somewhat less efficient than the generic/full table buffer. In the single-record table buffer, the data records must be added one after the other while reorganizing the frame structure. In the generic/full buffer, all the data of a table is transferred in one step, already sorted by the database.

Activities

Managing Non-Existent Records

The single-record buffer also stores information about nonexistent records of a table. If you attempt to access the table with a key that is not in the database, this information is stored in the buffer.

This is done with a flag that is added to every record stored in the buffer. The flag shows whether or not this record exists in the table. If you attempt to access a record that does not exist, an empty record is stored in the buffer with the corresponding key, and the flag is set to the value for a nonexistent record. If you try to access this record again, the system sees in the buffer that this record does not exist in the database.

We recommend single-record buffering if you repeatedly try to access nonexistent records of a table.

Displacement

If records of a table with single-record buffering are to be read and stored in the buffer and there is not enough space in the buffer, it is necessary to remove other records from the buffer for space reasons. The system removes from the buffer the records of the table that were least recently accessed.

Global Synchronization

The modifications made in the local buffers must be synchronized in distributed systems to keep the buffered data consistent. You can see the general procedure for synchronization in Synchronization of Local Buffers.

The effect of different ABAP commands on the local and global synchronization of the single-record buffer is described below.

●      If you make changes with WHERE conditions (UPDATE dbtab WHERE ..., DELETE FROM dbtab WHERE ...), the system invalidates the entire table in the buffer of the local server (server on which the command was submitted) and on all other servers at the time of the synchronization.

●      Changes without WHERE conditions (UPDATE dbtab, INSERT dbtab, DELETE dbtab) modify the corresponding records in the buffer of the local server and delete them in the buffers of all the other servers at the time of synchronization.

Modifications with a WHERE condition place a much greater load on buffer management than those without a WHERE condition.