Clarification needed on buffered table

[Peranandam]

Hi All,

when we are hitting buffered kind table(A900,T5UZC...etc).. table records are stored buffered and we are accessing buffered records for improving performance. But there is some case where we should not use buffered records which create data inconsistency. could please tell me when we can use buffered records and when we dont need to use buffered records. is there any limitation is there to hit buffered kind of table.

[former_member194613]

There are 3 important points:

+ First of all you should try to use the table buffer by writing SELECT statements which can use the buffer. Aggregate,

ORDER BY (not primary key), joins etc can not use the buffer.

+ the decision about inconsistency plays a major role when it is decided whether a table can be buffered at all. Buffered data are not always 100% up-to-date, i.e. if this important then table buffer is not useful for this data. Data should also rarely change, if the buffer should be used, because the changes create overhead. Application data are not suitable for table buffer, only customizing and some master data.

+ Sometimes - rather rarely - you have to read bypassing buffer from the table.

[Peranandam]

Thanks Siegfried Boes ....

You deserved answer for this thread. Is there any SNOTE is giving limitation/usage of Buffered tables. If buffered table is application table then we need to hit those table by passing buffer with select query (because of application table records can be change frequently), then why SAP is allowed to customer to buffer those kind of tables.

[ravi_lanjewar]

Hi,

In following cases buffer not work, You can check whether your problem exclude or inlude in buffer problem.

Native SQL

Subqueries, ABAP JOINs

SELECT ... BYPASSING BUFFER

SELECT FOR UPDATE

Aggregate functions (COUNT, MIN, MAX, SUM, AVG)

SELECT DISTINCT u2026

WHERE clause with "IS NULL"

ORDER BY, GROUP BY (HAVING)

For tables with single record buffering:

All SQL statements except SELECT SINGLE ...

For tables with generic buffering:

*All SQL statements except SELECT ** .. if WHERE clause is*

field = value for all fields included in generic area

Buffer reading problem may be occurs only in case of multiple application server.

In general sinario it read first from buffer and then go to futher reading of data from database.

Rgds

Ravi Lanjewar

[former_member194613]

---

01 SELECT must contain all buffered fields with equal condition

or an IN-list with a single value, if not then buffer is bypassed

-

---

03 To access single record buffer the SELECT must contain

the keyword SINGLE (up to basis EhP1)

04 SELECT DISTINCT u2026

05ORDER BY, GROUP BY (HAVING)

06Aggregate functions (COUNT, MIN, MAX, SUM, AVG)

08 Subqueries,

09 ABAP JOINs

12 WHERE clause with "IS NULL"

13 Native SQL

14 SELECT ... BYPASSING BUFFER

15 SELECT FOR UPDATE

Additionally there are

02 IN-list with more than one value

07 FOR ALL ENTRIES can not use single record buffer

10 On the database WHERE conditions like f1 = f5 are possible, they can

not use the table buffer

11 Using CLIENT SPECIFIED without a specified client can not use the buffer

All changes bypass the buffer and have some overhead effects on the buffer.

[former_member192616]

Addiotnally (as I learnt recently):

SELECT statements that are executed under isolation level "READ_COMITTED" mode.

Kind regards,

Hermann

[former_member194613]

> In general sinario it read first from buffer and then go to futher reading of data from database.

it is the other way round First to the db, fills the buffer, later the buffer is used.

[former_member192616]

Hi,

> > In general sinario it read first from buffer and then go to futher reading of data from database.

> it is the other way round First to the db, fills the buffer, later the buffer is used.

i would say,

first look up the buffer if data is there use it,

if data is not there load from the database into the buffer,

then use data in the buffer,

...

Kind regards,

Hermann

[former_member208517]

It is complicated question.

For sap standard table, sap will defined the buffering type. Normally ,we need not care about it.

In most case, SAP's setting is always right.

SAP also supplied alternate ways to bypass the buffer using which was mentioned in above replies.

Talking about the addon Z-table, the buffering setting is depending on the experience of the developer.

SAP clearly announce the rule to buffer the tables, indicating which kindly of the d/b table should use what kind of the buffer type.

Frankly speaking, you need not worry about the buffering problem. Problem may caused by buffering will be eliminated through buffering setting by the developer.