Single-Record Table Buffers
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 data area is organized in frames of a fixed size (default value 4 KB).
The table names are sorted 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, however, all the data of a table is transferred in one step, already sorted by the database.
Managing Non-Existent Records
The single-record buffer also stores information about non-existent 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 non-existent record. If you try to access this record again, the system sees in the buffer that this record does not exist in the database.
Single-record buffering is also recommended if you repeatedly try to access non-existent records of a table.
If records of a table with single-record buffering are to be read and stored in the buffer, it might be necessary to remove other records from the buffer for space reasons. In this case, the records of the table that were least recently accessed are removed from the buffer.
The modifications made in the local buffers must be synchronized in distributed systems in order to keep the buffered data consistent. The general procedure for synchronization is described inSynchronization of Local Buffers.
The effect of different ABAP commands on the local and global synchronization of the single-record buffer is described below.
If changes are made with WHERE conditions (UPDATE dbtab WHERE ..., DELETE FROM dbtab WHERE ...), the entire table is invalidated 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 therefore place a much greater load on buffer management than those without a WHERE condition.