Regarding Technical Setting of Tables.

[anup_deshmukh4]

Hey Hi Experts,

I have following issues within my implementation project.

1. On the PRD server the data is huge when i see Transaction tables like VEPO or LIPS I see that the size Category specified ( in my case vepo is set for Catagor 4 ie 81,000 to 320,000 records but it far exceeds the limits current is 6 lacks ) in the technical setting is very low as compared to the data size in them ( Will that matter my Reports performance )

2. There is a radio button goup where its set to "NO Buffring allowed " (Caution ..!)

I need you suggession for the following do i need to adjust the technical setting of the tables if my data size is exceding the limit specified record count .

If ineed to set it What type of buffring will i choose.

Plz experts...:)

[former_member192616]

Hi Anup,

the size Category has no influence on your report performance. On ORACLE plattforms it used to be evaluated in order to derive extent sizes. This is not the case anymore. I don't know if it still does play a role for other databases (i would assume not) or if it is evaluated when you migrate a system to another database plattform. However changing this value will not influence your report performance.

For the buffering: If the flag says no buffering allowed don't touch it

In general for SAP tables only change this setting when you are advised to do so in sap notes or messages.

For your own tables you might cosinder buffering if

- temporary outdated data on remote application servers is acceptable

- the to be buffered data is rarely changed and read often

- the to be buffered data is not too big compared with the configuration

Kind regards,

Hermann

[former_member555112]

Hi,

The size category means the no of memory blocks SAP will reserve for that particular table in the database.

It does not mean that the table can contain only those many records. It means that SAP will reserve that much memory size of the block.

When the table records have become more than that block ; SAP will reserve one more memory block of that much size and so on.

Buffering is to be done only for small tables whose data does not change very frequently.

For example the master tables like T001 or T001W.

For this table the data is not going to change frequently. Hence buffering them make efficient.

Incase of large tables like LIPS, VBAP which store the transactional data; buffering does not make any sense and hence you should not buffer them.

For more info go through the following link.

[http://www.sapnet.ru/abap21day/ch05/ch05.htm#DataClass]

Regards,

Ankur Parab

[anup_deshmukh4]

Thanks for your inputs,

My issues that I am Generating a Packing list Report using the Tables the Data Set i am retrieving is very large..

How am i going to optimize it Coz.

VEPO is a table where i need to recursively access the records like i get a

VENUM I get a record

i have to again Search the same table Using UNVEL as my next VENUM

and this can go to N' level deep. ( i have 6-10 level of packing )

The data i am getting is huge..how am i going to optimize it ..

Plz. Plz i need your inputs

[former_member555112]

HI,

Use the FM HU_GET_HUS instead.

This FM will get you all the details which you need from VEKP and VEPO.

Or use the BAPI BAPI_HU_GETLIST.

Regards,

Ankur Parab

[Former Member]

1) When you activate a table for the first time the system needs to know how much space it needs to reserve for your table. Your definition tells the system the maximum size in bytes for each record. All the system needs to know is how many records (a ball park figure) your table is likely to have. This is what you enter in the size (category). This does not mean that your table cannot exceed that size. When your table is about the exceed the specified size the system needs to allocate more space. How does it know how much space it needs to allocate? Again it looks at this technical setting value. In short the category indicates to the system the amount of disc space to allocate/reallocate your table.

Will this effect your query speed? No.

2) Buffering determines how many records are transferred from the database to the memory. If you use full buffering any query to the table will cause all the records in the table to be transferred into your buffer. This setting is acceptable for smaller tables. You would not want to do this with larger tables because you will not have enough space in the memory to read all the data. The partial buffering transfers all the records that qualify by part of the primary key. For example if you are reading VBAP (Sales Order Line table), if you repair the table to have partial buffering and you read one sales order (VBELN) the system automatically transfers all the data of all the lines (POSNR) of the sales order from the database to the buffer.

Buffering helps improve performance but careful thought needs to be put into this and besides it is not advisable to repair any SAP tables.

The best solution for large tables is archiving. The SAP R/3 system should not be used to view reports on historic data. We have the BW system for that. The BW system is designed to be flexible with data and can quickly give you the historical reports you desire. It is a best practice to archive large tables every 2 years and use the BW system for the historical data analysis.

[former_member194613]

> 2) Buffering determines how many records are transferred from the database to the memory. If you use full buffering

> any query to the table will cause all the records in the table to be transferred into your buffer.

this is not the main point of buffering, Buffering means that the same data are read once from the database into the buffer of the application server. All later Open SQL statements are directed to the buffer and not to the db.

=> fully buffered fills the whole table into the buffer, i.e. only one db access, all others go to the buffer

Of course things become more complicated if the data change.

Siegfried

[Former Member]

Is It possible to automatic change Technical Setting. Table working is fine but when we go to on Technical setting message is appears that " No technical setting is found". have u any solution.

[Former Member]

You must not use buffering for large tables.