Internal Table storage space problem

[Former Member]

Hi,

i am appending some 10 laks of records to an internal table but after some time it leads to short dump by showing the following error.

Short text

No more storage space available for extending an internal table.

What happened?

You attempted to extend an internal table, but the required space was

not available.

Please help me what to do, the arrow is showing at the position of 'append' statement.

-

---

GP

[Former Member]

hey just paste ur code may be there is proble.

but otherwise this is due to memory space contect ur basis person to increase memory space.

[Former Member]

Hi am sending the code , error arrow is pointing at the append statment.

its a form am calling in 3 nested loop.

FORM log_conflict .

w_rtab-userid = w_utab-bname.

w_rtab-usergrp = w_utab-class.

w_rtab-grp1 = w_etab-grp1.

w_rtab-grp2 = w_etab-grp2.

w_rtab-sox = w_etab-sox.

IF w_uttab1-parent GT c_sp.

w_rtab-parent1 = w_uttab1-parent.

ELSE.

w_rtab-parent1 = c_sp.

ENDIF. "w_uttab1-parent

w_rtab-role1 = w_uttab1-role.

IF w_uttab2-parent GT c_sp.

w_rtab-parent2 = w_uttab2-parent.

ELSE.

w_rtab-parent2 = c_sp.

ENDIF. "w_uttab2-parent

w_rtab-role2 = w_uttab2-role.

IF p_detail = c_check.

w_rtab-trcd1 = w_etab-trcd1.

w_rtab-trcd2 = w_etab-trcd2.

APPEND w_rtab TO t_rtab.

ELSE.

w_rtab-roleau1a = ''.

w_rtab-roleau1b = ''.

w_rtab-roleau2a = ''.

w_rtab-roleau2b = ''. "If summary do not report tcode and auth

collect w_rtab into t_rtab. "info and do not have duplicate entries.

ENDIF. "p_detail

CLEAR w_rtab.

[Former Member]

There is a limit on how much memory an internal table can use at a time in a session. This can be set by system administrator. I think it is not a good idea to increase the memory allocation because in that case the program will not work in systems where memory settings are not manipulated. You may consider writing the table to database after every 100,000 records (say) and clearing the internal table. Later you may read the database table using open cursor and package size for processing.

[VinayPrasad_PM]

Hi,

This depends on virtual memory and file space of the operating system. Before Release 4.0A, ABAP stored the content of internal tables in a combination of main memory and file space. This means that the maximum size of all internal tables of all programs running on such an application server at one time is about 2 GB. With Release 4.0A or greater, this size decreases to about 500 MB.

Note that those values aren't fixed, but this is a good guide. This minimum of 500 MB is the lowest limit of the real value, which varies among different operating systems.

This is strange that a newer release has a higher restriction on capacity. But it's a consequence of the fact that the contents of internal tables move from a reserved file to shared memory. When you process internal tables this way in Release 4.0A or greater, you pay for much better performance with a smaller potential size.

you have to redesign your program in a way that the complete data is split into different logical parts that each, on its own, can be processed by ABAP.

Regards,

Vinay

[Former Member]

I think you either need to redesign your code to process data in packages (use package size in the select statement) or use field-groups instead of internal tables (if your logic allows as field-groups have some limitations). Field-groups are stored in the file rather than memory so you should be able to process really big datasets.... but there are limitaitons - check sap help for field groups.

would be good to check your logic to make sure you select only necessary fields, avoid duplicates since with such a big data volumes it's better not to append duplicates at all then append & remove later.

Another option would be to use select/endselect ... I would definitely use select with package size to achieve a balance between good performance and acceptable table size.

[Former Member]

Hi Giri,

Some general recommendations for internal tables:

• As long as all that you need from an internal table is to append lines to it and perhaps to sort it after filling it, standard tables are still the best choice. The other table kinds are too expen-sive for these simple tasks. Keep in mind that when inserting or deleting lines in index tables containing many lines, the administration of the logical index that manages the lines of the ta-ble internally can become expensive, with regard to performance and additional memory space. Only for standard tables that are filled with APPEND only, and where no lines are de-leted except for the last line, is there no need for a logical index, and hence no additional costs are incurred.

<i><b>•If memory space is an issue, for very large internal tables (> 500000 lines) with a small line size, sorted tables might be preferable to hashed tables, since for internal administration, they need only 6 bytes per line compared to 18 bytes for hashed tables.</b></i>

<i>•When declaring internal tables, use the addition INITIAL SIZE only for inner tables in nested tables. For outer tables, the automatic allocation of initial memory size is appropriate. For inner tables, though, it may result in saving a large amount of memory.</i>

•When reading internal tables with READ TABLE or LOOP AT, choose the appropriate output behavior. Writing into a work area wa with the addition INTO wa is only necessary if you want to change the work area without influencing the internal table. For pure reading purposes or for modifying the contents of the internal table, the additions ASSIGNING <fs> for assigning internal table lines to a field symbol <fs> and REFERENCE INTO dref for setting a refer-ence in a data reference variable dref to internal table lines are the better choices by far.

•Use CLEAR instead of REFRESH for internal tables. The reason is that for internal tables with-out header lines, the general statement CLEAR does exactly the same as the special state-ment REFRESH. Since internal tables with header lines should no longer be used, the state-ment REFRESH is effectively obsolete. In order to free more memory, you can consider the use of FREE.

•The statement COLLECT should no longer be used for standard tables — use COLLECT mainly for hashed tables. The reason is that COLLECT is based on a hash algorithm. While the hash administration of a hashed table is always available and robust, for standard tables a temporary hash administration must be created when the COLLECT statement is used. This temporary hash administration is invalidated when the table is accessed for changing. If fur-ther COLLECT statements are entered after an invalidation, a linear search of all table rows must be performed. Furthermore, COLLECT only works properly on internal tables with unique lines, while a unique table key is guaranteed for hashed tables only. Therefore, for standard tables it cannot be guaranteed that the contents will always be suitable for editing using COLLECT.

•Don’t use APPEND SORTED BY — use SORT instead. The reason is that creating a ranked list with APPEND SORTED BY is based on several assumptions about the internal table and how it is filled. Using SORT is the general method that can be applied to all kinds of table and inde-pendent from the mode of filling.

Regards,

Balaji Reddy G

**Rewards for helpful answers