data dictionary

[Former Member]

1) how buffering helps us?which type of buffering we will use?

2) how table maintanence generator helps us in creating database table?

[Former Member]

1)Buffering is the property that can be set for a database table. It means that the records of this table are in the buffer for faster access. You can specify whether you want to buffer the entire table or a single record.

The Individual Buffering Types :

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.

Permanent buffering can lead to problems when you are testing your Customizing settings. The Context Builder therefore allows you to de-activate the context buffer (buffering type P) during the current terminal session. To do this, choose Settings ® Buffering. The system displays a dialog box. Select Inactive, and choose Continue. You can activate or de-activate the context buffer for a particular user by setting the user parameter BUF to Y or SPACE (default) or N using the Maintain users transaction (SU01).

2)use for make table entry directly into table.

[Former Member]

Hi Jyothi,

1)Buffering is the property that can be set for a database table. It means that the records of this table are in the buffer for faster access. You can specify whether you want to buffer the entire table or a single record.

1. You should buffer tables that are mostly read and rarely changed, which is why certain inconsistencies are acceptable. Buffering is recommended for smaller tables. Large tables are usually indexed.

2. Choose the buffer granularity for the table carefully. This depends on the following issues:

¡ The expected size of the table. Full buffering is not recommended for large tables.

¡ Read accesses. To use the buffer you have to provide the defined key range – that is, the generic key and the primary key.

¡ Non-existent data. With single records buffering each not found record is stored as an entry. For generic area buffering an entry is stored for each not found generic area. The potential overload is avoided when you use full buffering. We recommend that you use full buffering for empty tables with frequent write accesses.

3. It is important to choose an appropriate generic key. A short generic key may lead to a large number of buffered records. A large generic key usually means a small number of buffered records. The queries then often will bypass the buffer and buffering will not be efficient.

2)We can use Table Maintenance generator is required to do user as manually in table entries.

suppose if u want to update a table automatically rather programatically u can go for tbale maintenance generator

Manual entries in table can be maintained ( New record can be inserted / existing can be modified )

use transaction SM 30, if the table maintenance for the table is generated.Using SM30 we enter data into the table.This updates the table and a Database is created for that table.So it create a database table.

http://help.sap.com//saphelp_470/helpdata/EN/a7/5133ac407a11d1893b0000e8323c4f/frameset.htm

http://help.sap.com/saphelp_nw04/helpdata/en/cf/21ed2d446011d189700000e8322d00/content.htm

http://help.sap.com/saphelp_46c/helpdata/en/a7/5133ac407a11d1893b0000e8323c4f/frameset.htm

steps :

Goto SE11 and open the table.

Click UTILITIES -> Table Maint. Generator,

Enter the details

click on Save.

activate the table.

Regards,

Priyanka.

[amol_chaudhari5]

<b>Buffering Permission</b>

You must define whether and how a table is buffered in the technical settings for the table.

There are three possibilities here:

_ <i>Buffering not permitted: </i>Table buffering is not permitted, for example because application programs always need the most recent data from the table or the table is changed too frequently.

_ <i>Buffering permitted but not activated</i>: Buffering is permitted from the business and technical points of view. Applications which access the table execute correctly with and without table buffering. Whether or not table buffering will result in a gain in performance depends on the table size and access profile of the table (frequency of the different types of table access). Table buffering is deactivated because it is not possible to know what these values will be in the customer system. If table buffering would be advantageous for the table size and access profile of the table, you can activate it in the customer system at any time.

_ <i>Buffering activated:</i> The table should be buffered. In this case you must specify a

buffering type.

<b>Buffering Types</b>

The buffering type defines which table records are loaded into the buffer of the application server when a table record is accessed.

There are the following buffering types:

_ <i>Full buffering:</i> All the records of the table are loaded into the buffer when one

record of the table is accessed.

_ <i>Generic buffering:</i> When a record of the table is accessed, all the records

having this record in the generic key fields (part of the table key that is left-justified,

identified by specifying a number of key fields) are loaded into the buffer.

_ <i>Single-record buffering:</i> Only the records of a table that are really accessed

are loaded into the buffer.

Full Buffering

With full buffering, either the entire table is in the buffer or the table is not in the buffer at all. All the records of the table are loaded into the buffer when one record of the table is read.If the table is fully buffered, all the records of the table are loaded into

the buffer.

The buffered data records are sorted in the buffer by table key. Accesses to the

buffered data can therefore only analyze field contents up to the last specified key

field for restricting the dataset to be searched.

The left-justified part of the key should therefore be as large as possible in such

accesses.

For example, if you do not define the first key field, the system has to scan

the full table. In this case direct access to the database can be more efficient if the

database has suitable secondary indexes.

When Should you Use Full Buffering?

When deciding whether a table should be fully buffered, you should take 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, read frequently, and rarely written.

Full buffering is recommended in the following cases:

_ Tables up to 30 KB in size. If a table is accessed frequently, but all accesses are read accesses, this value can be exceeded. However, you should always pay attention to the buffer utilization.

_ Larger tables where large numbers of records are frequently accessed. If these mass accesses can be formulated with a very selective WHERE condition using a database index, it could be better to dispense with buffering.

_ Tables for which accesses to non-existent records are frequently submitted. Since all the table records reside in the buffer, the system can determine directly in the buffer whether or not a record exists.

Generic Buffering

With generic buffering, all the records in the buffer whose generic key fields match this record are loaded when one record of the table is accessed. The generic key is a part of the primary key of the table that is left-justified.

When Should you Use Full Buffering?

A table should be buffered generically if only certain generic areas of the table are normally needed for processing. Client-specific, fully-buffered tables are automatically generically buffered since normally it is not possible to work in all clients at the same time on an application server. The client field is the generic key. Language-specific tables are another example where generic buffering is recommended. In general, only records of one language will be needed on an application server. In this case, the generic key includes all the key fields up to and including the language field.

How Should you Define the Generic Key?

In generic buffering, it is crucial to define a suitable generic key.

If the generic key is too small, the buffer will contain a few very large areas. During access, too much data might be loaded in the buffer.If the generic key is too large, the buffer might contain too many small generic areas. These can reduce buffer performance since there is an administrative entry for every buffered generic area. It is also possible that too many accesses will bypass the buffer and go directly to the database, since they do not fully define the generic key of the table. If there are only a few records in each generic area, it is usually better to fully buffer the table. Only 64 bytes of the generic key are used. You can specify a longer generic key, but the part of the key exceeding 64 bytes is not used to create the generic areas.

Access to Buffered Data

It only makes sense to generically buffer a table if the table is accessed with fully-specified generic key fields. If a field of the generic key is not assigned a value in a SELECT statement, it is read directly from the database, bypassing the buffer.

If you access a generic area that is not in the buffer with a fully-specified generic key, you will access the database to load the area. If the table does not contain any records in the specified area ("No record found"), this area in the buffer is marked as non-existent. It is not necessary to access the database if this area is needed again.

Single-Record Buffering

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.

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.

Regards,

Amol C.

• Don't forget to add points for helpful answers.

[Former Member]

Use of buffered tables is recommended to improve the performance considerably. The buffer is bypassed while using the following statements

1. Select distinct

2. Select … for update

3. Order by, group by, having clause

4. Joins

Use the Bypass buffer addition to the select clause in order to explicitly bypass the buffer while selecting the data.

Buffering Types

· 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.

Permanent buffering can lead to problems when you are testing your Customizing settings. The Context Builder therefore allows you to de-activate the context buffer (buffering type P) during the current terminal session. To do this, choose Settings ® Buffering. The system displays a dialog box. Select Inactive, and choose Continue. You can activate or de-activate the context buffer for a particular user by setting the user parameter BUF to Y or space (default) or N using the Maintain users transaction (SU01).
Construction of the Buffer

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.

Note

When you create your own contexts, you should bear in mind the advantages of this buffering concept. Try to include as many relationships between data objects in a single context for each program, rather than using several contexts in the same program. You can also combine a group of contexts as modules of a single, larger context. In a single context, the system buffers all the interim results in an optimum way. With different contexts, the individual buffers do not affect one another.
Deleting a Buffer
You can delete the contents of a context buffer as follows:
· in the Context Builder (Transaction SE33), choose Edit ® Delete buffer ® Local server to delete the buffer contents for a context on the current application server, or Edit ® Delete buffer ® All servers to delete the buffer contents for a context on all application servers.
You can use these functions when testing or buffering contexts.
· in ABAP programs, you can use the function modules CONTEXT_BUFFER_DELETE_LOCAL and CONTEXT_BUFFER_DELETE to delete the buffer contents for a context on the local server or all servers respectively.
You can use these function modules in conjunction with changes to database contents to ensure that the contents of the context buffer are always current.

Example

The following is an example which you could use in asynchronous update:

DATA context_name LIKE rs33f-frmid.

context_name = 'DOCU_TEST1'.

CALL FUNCTION 'CONTEXT_BUFFER_DELETE' IN UPDATE TASK

EXPORTING

context_id = context_name

EXCEPTIONS

others = 0.

COMMIT WORK.

In the example, the system calls CONTEXT_BUFFER_DELETE as an update module. You could use it as the last update call following the database changes before the COMMIT WORK statement.