Table Creation

[Former Member]

Hi,

Can anybody tell me what is eant by buffering in the technical settings during table creation

regards,

Manish

[Former Member]

Hi

Actually Technical Setting is to identify the Size of the Table Created and to Set whether buffering needs to be done for the table or not.

Buffering

It will reduce the Network tarffic but disadvantage is it will not update the Server back immediately

Regards

Divya

Edited by: DIVYA VENKATAKRISHNAN on Jul 11, 2008 7:56 AM

[Former Member]

hi,

The Option of Buffering in the Technical Setting is to tell the compliler that the a buffer area should be maintained for this table or not.

Plz check out this link.

https://help.sap.com/saphelp_nw04/helpdata/en/f1/f5c2deca023d4bb7dfeaf5eda45307/content.htm

regards

Sumit Agarwal

[Former Member]

Hi,

Find the below topic on buffering and it clearly explains the purpose of buffering.

Table buffering concept will be used to apply the shared access of the table entries.

Single-record buffering

With this kind of buffering, only the records of a table which are actually accessed are loaded into the buffer.

This kind of buffering requires less storage space in the buffer than full buffering. However, greater organization is necessary and considerably more database accesses are necessary for loading.

If an as yet unbuffered record is accessed using SELECT SINGLE, a database access occurs to load the record. If the table does not contain a record for the specified key ('no record found'), this record is noted as nonexistent in the buffer. If a further attempt is made to access this record using SELECT SINGLE, a renewed database access can be avoided.

When should single-record buffering be selected?

For large tables where there are frequent single-record accesses (using SELECT SINGLE ...). The size of the records being accessed should be between 100-200 KB.

For comparatively small tables for which the access range is large, it is normally advisable to opt for full buffering. Only one database access is required to load such a table for full buffering, while single-record buffering calls for a very large number of table accesses.

(ii) Generic buffering

In a read access to a record of a generically buffered table, all the records whose left-justified part of the key (generic area) corresponds are loaded into the buffer.

If this type of buffering is selected, the generic area must be defined by specifying a number n of key fields. The first n key fields of the table then define the generic key.

The number of key fields to be entered must lie between 1 and the number of key fields -1. For example, only values between 1 and 5 are permitted for a table with 6 key fields. The client field is included here.

When should generic buffering be selected?

A table should be buffered generically if usually only certain areas of the table are required. The individual generic areas are treated like independent tables that are fully buffered. Refer also to the text on complete buffering.

The generic key area should be selected so that the generic areas are not too small to prevent too may generic areas being produced. If there are only a few records for each generic area, it is more efficient to use full buffering.

Generic buffering only makes sense if the table is accessed by a specified generic key. If, when an access takes place, a field of the generic key is not supplied with a value, the buffer is ignored and the records are read directly from the database.

Language-specific tables are an example of good use of generic buffering (with the language key field as generic key area).

(iii) Full buffering

With full buffering, either the complete table or none of the table is in the buffer. If a read access is made to a record, all records of the table are transferred to the buffer.

When should you select full buffering?

For tables up to 30 KB in size. If a table is accessed frequently, but all accesses are read accesses, this value can be exceeded.

For larger tables where large numbers of records are frequently accessed. However, if the application program is able to formulate an extremely selective WHERE condition using a database index, it may be advisable to dispense with full buffering.

For tables with frequent accesses to data not contained in the table. Since all records are contained in the buffer, a quick decision can be made as to whether or not the table contains a record for a specific key.

When considering whether a table should be fully buffered, you should take three aspects into account: the size of the table, the number of read accesses, and the number of write accesses. Tables best suited to full buffering are small, frequently read, and rarely updated.

[Former Member]

Hiii!

Check out these links

http://www.abapprogramming.net/2007/06/lesson-12-abap-dictionery.html

http://abapdictionary.blogspot.com/2007/10/indexing-and-buffering.html

Regards

Abhijeet Kulshreshtha

[Former Member]

Hi,

Buffering a table improves the performance when accessing the data records contained in the table.

The table buffers reside locally on each application server in the system. The data of buffered tables can thus be accessed directly from the buffer of the application server. This avoids the time-consuming process of accessing the database.

For more details refer the following link:

http://help.sap.com/saphelp_nw70/helpdata/en/cf/21f244446011d189700000e8322d00/content.htm

Hope this will help you.

Thanks

Yogesh Sharma

[Former Member]

Hi,

Buffering means when u fetch the datas from database

it first time it fetch the data from database and put it into buffer

if u execute it will check the buffer if buffer is empty then it will fetch from database.

So time to acces the database is reduse.