abap dictionary

[Former Member]

How can we create Buffer?

[seshatalpasai_madala]

Hi,

Are you asking about buffering database table entries.

Then goto Technical settings of any database table and Press F1 on Buffering radio buttons.

If you are asking about storing your data some where and then getting it back using some other program then you can think of SET/GET Parameter or IMPORT EXPORT commnads.

Regards,

Sesh

[paruchuri_nagesh]

hi

when creating ztable goto techinicalsettins

there u can specify required settings

reward for use ful answers

Nagesh.Paruchuri

[Former Member]

hi,

while creating a table in <b>TECHNICAL SETTINGS</b>,

there r 3 options like ,

<b> Buffering not allowed

Buffering allowed but switch off

Buffering On

</b>

The buffering status specifies whether or not a table may be buffered.

This depends on how the table is used, for example on the expected

volume of data in the table or on the type of access to a table. (mainly

read or mainly write access to the table. In the latter case, for

example, one would not select buffering).

You should therefore select

- Buffering not allowed if a table may not be buffered.

- Buffering allowed but not activated if buffering is

principally allowed for a table, but at the moment no buffering

should be active. The

buffering type specified in this case is only

a suggestion.

- Buffering allowed if the table should be buffered. In this

case a buffering type

must be specified.

With Rgds,

S.Barani

[Former Member]

hi anil,

while ur creating table at one step u will be going for technical settings there in that screen u will find the options like Buffers allowed,Buffers not allowed, Buffers allowed with restrictions like three radio buttons if u select Buffers allowed radio button then that table will be having buffers memory which will be stored in Application server ..............................................

the concept of buffers>>>>>>

if the table data is frequently used then that table is assained with buffers

buffers r of type three types

1) Single record buffers

2) full record buffers

3) Generic buffering

single record buffering.. if the table is single record buffered then while u have written a select quiry to fetch the single record from that table that required single record will be stored in the buffer area in the application server.we can select the single record buffere if the table memory capacity is more than 30kb

Full record buffering.. we can select the full trecord buffering for the table of memory capacity less than 30kb if a single a single record is fetched from the table then by default all the records in that table will be fetched n stored in the buffer area

Generic buffering.. if a record is fetched from the table all the satisfied generic key field will be fetched n stored in the buffer

if the answree is satisfied reward with points

[Former Member]

Hi,

<b>The Individual Buffering Types</b>

Permanent (P)

This is the default buffer setting, in which the cross-transaction application buffer is

used. For more information about this buffer, see the keyword documentation for

EXPORT/IMPORT TO/FROM SHARED BUFFER. The cross-transaction application buffer can contain up to 128 context entries. These entries are structured using a process similar to LRU (Least Recently Used).

To display the contents of the context buffer on the current application server, choose Goto -> Display buffer in the Context Builder. The buffer is reset every hour on the hour. You can also reset it manually in the Context Builder by choosing Edit -> Reset buffer. This resets the buffer on all application servers.

Temporary (T)

If you choose this buffer type, the derived data is only buffered within a transaction.

Within a transaction the buffer can contain up to 1024 entries. These entries are

exported in bundles into the cross-transaction application buffer. The results of the

various instances of a context are stored in the same buffer within the program.

No buffer (N)

If you choose No buffer, the derived data is not buffered. If you use this buffering type for all modules in a context, using the context will not improve system performance, but is merely a way of re-using program logic.

<u><b>Construction of the Buffer</b></u>

The context buffer contains two buffer tables for each module:

The I buffer (internal buffer), which saves each combination of module input parameters queried during the lifetime of the buffer, along with their derived values.

The E buffer (external buffer), which assigns the derived values in the module to the key values in the context. The E buffer is filled each time a query is made. The first time a query is made using a particular combination of module input parameters, the results are written to the I buffer without any reference to the key values for the context. If, however, the same combination of module input parameters is queried more than once (so that the combination already exists in the I buffer), the system writes the results to the E buffer along with the context key values). It is therefore possible for the results of a particular combination of module input parameters to appear more than once in the E buffer, since

different combinations of key fields can lead to the same set of module input parameters.

The various modules within a context are linked by the derivation schema. The input parameters of a module are either key fields or output parameters of another module. The entries in the E buffer for modules which depend on other, previous modules are the same as the I buffer entries for those previous modules. The buffering type of the E buffer for the dependent module is the same as the lowest buffering type of any of the modules on which it depends. Thus, if one of the

previous modules has buffering type N, the system will not store any entries in the E buffer of the dependent module.

When you access the context buffer, either during testing or using the DEMAND statement, the system first searches in the E buffer of each module, followed by the I buffer. Access to the E buffer is more direct, and quicker than using the I buffer, which usually needs to be accessed more often.

The inclusion of entries in the E buffer which have been queried more than once is an acceptance of data redundancy as the price for quicker access. The I buffer is a filter for the E buffer, only allowing redundant data when absolutely necessary. Together, the I and E buffers provide a balance of quick access time and high probability of finding an appropriate entry.

Regards,

Bhaskar