short dump-internal table size issue

[Former Member]

Hi,

I get the following message in the short dump analysis for a report.

***********************

No storage space available for extending table "IT_920".

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

Error Analysis:

The internal table "IT_920" could not be enlarged further.

To extend the internal table, 9696 bytes of storage space was

needed, but none was available. At this point, the table "IT_920" has

1008240 entries.

*************************

Its an old report and I saw the internal table declaration using the "OCCURS" clause in the internal table declaration.

begin of itab occurs 100.

.

.

end of itab.

I tried the option of changing to "OCCURS 0", still issue persists.

Any help would be highly appretiated

CM

[Former Member]

just give...

<b>begin of itab occurs 0.

.

.

end of itab.</b>

otherwise just go through this link(abt pacage size)

can u just paste ur code..(u append data on same internal table or diffrent)

Message was edited by: kishan negi

[FredericGirod]

Hi,

this is an administration problem, not an ABAP. You need to ask to your favorite administrator to add memory, or to modify the RZ10 parameters for the memory available for internal table.

In the ST22 you must have the description of the parameter to modify

Rgd

Frédéric

[nishanthbhandar]

Declare the table as a standard table with initial size as 0.If the storage space is still a problem contact BASIS.

Cheers

Nishanth

[Former Member]

Thank you all for the replies.

But I forgot to mention that the program is terminating at an "APPEND" atatement; ie, when it is trying to add another record to the internal table inside a loop.

[Former Member]

Hello CMV,

This is basic problem with SAP internal tables. For every internal table memory is alocated ( Max..256K)...once you cross the memory size/limit of the internal table it resuls in short dump.

Only way to overcome this problem is handle limited number of records at a time..

Please refer following sample code which will help you to avoid short dump while processing large number of records....

SORT TAB_RESULT.

DESCRIBE TABLE TAB_RESULT LINES W_RECORDS.

W_LOW = 1.

W_UP = 1000.

*Spliting the records from tab_result1 by pakage of 1000 at a time

*to avoid short dump in case of more records

WHILE W_LOW <= W_RECORDS.

R_PKUNWE-SIGN = 'I'.

R_PKUNWE-OPTION = 'EQ'.

R_WERKS-SIGN = 'I'.

R_WERKS-OPTION = 'EQ'.

LOOP AT TAB_RESULT FROM W_LOW TO W_UP.

MOVE TAB_RESULT-PKUNWE TO R_PKUNWE-LOW.

MOVE TAB_RESULT-WERKS TO R_WERKS-LOW.

APPEND R_PKUNWE.

APPEND R_WERKS.

ENDLOOP.

*fetch sold to party

SELECT KUNNR NAME1

FROM KNA1

APPENDING CORRESPONDING FIELDS OF TABLE TAB_KNA1

WHERE KUNNR IN R_PKUNWE.

*fetch plant

SELECT WERKS NAME1

FROM T001W

APPENDING CORRESPONDING FIELDS OF TABLE TAB_T001W

WHERE WERKS IN R_WERKS.

REFRESH: R_PKUNWE,

R_WERKS.

W_LOW = W_LOW + 1000.

W_UP = W_UP + 1000.

ENDWHILE.

Hope this will help you to solve problem.

Cheers,

Nilesh

[Former Member]

Hi CMV,

At the time of appending record to internal table it is not getting the memory space to hold it.

Ask Basis peaple to for this to extend the memory availability .

Regards

Kishor

[Clemenss]

Hi,

it is hard to see the need for 1008240 table entries in memory. If you really need them, first analyze the table structure: delete all except the fields really used and use select into corresponding fields of.

Another possibilty might be the blockwise procesing of data.

This should help without memory add-on.

regards,

Clemens

regards,

[Former Member]

i work in an application maintenence project. i am not very sure about the volume of data.

[Former Member]

hi

check this out

OCCURS Value or INITIAL SIZE Specification

Internal tables are a dynamic data structure. Their memory requirements are met in blocks. The initial memory allocation (hereafter called the OCCURS area), can be controlled using the " OCCURS n" or "INITIAL SIZE n " addition in the table definition (see DATA, TYPES). Once the OCCURS area is full, the next block to be created is twice as big as the OCCURS area (as long as this is not greater than 8 KB). All further blocks are then created with a constant size of 12 KB.

You can leave it to the system to determine the size of the OCCURS area by specifying n = 0. In this case, the system allocates only a "small" portion of memory at the first INSERT or APPEND statement. "OCCURS 0" or "INITIAL SIZE 0" means that 16 <= n <= 100 (depending on the line width).

It only makes sense to specify a concrete value of n > 0 when you know exactly how many entries the table will have, and you want to set up the OCCURS area exactly. This can be particularly important if you want to nest internal tables (where an "outer" internal table contains one or more other internal tables in each line, and the "inner" tables only have a few entries (no more than 5, for example).

To avoid excessive memory requirements, the system handles large values of n as follows: The largest possible value of n is n_max = 8 KB divided by the line width. For larger values, n is set such that n multiplied by the line width is around 12 KB.

plz reward if useful

[Former Member]

Hi,

This is an BASIS issue.

You can also declare it as occurs 0, since u are having the information priorly about large volume of data.

Regards,

Bharadwaj