topic Internal Tables in Application Development and Automation Discussions

Internal Tables

Former Member — Thu, 25 Jan 2007 04:47:18 GMT

Hi,

Please tell me at the maximum no of records that an internal table can hold...so that it should not give a dump saying "cant extend the internal table"?

Thanks,

Vijaya

Re: Internal Tables

Former Member — Thu, 25 Jan 2007 04:50:27 GMT

depends on your memory allocation. There is no limit on the internal table,

refer.

Re: Internal Tables

Former Member — Thu, 25 Jan 2007 04:52:17 GMT

Hi Vijaya,

The memory allocation of internal table is not fixed to some limit. It goes on increasing once u add the data and decreases when data is deleted from the table. So you can add as much data you require.

Regards,

-Priyanka.

Re: Internal Tables

Former Member — Thu, 25 Jan 2007 04:54:16 GMT

Hi,

That depends on the internal table type u have declared...

Internal tables of standard may cause dump for more number of entries..

If u reallly have a lot of data say..more than lakh entries... better go for hashed tables..

Thanks

Rajiv

Re: Internal Tables

Former Member — Thu, 25 Jan 2007 04:56:05 GMT

it will depend on the memor allocated by basis,

please consult ur basis

Re: Internal Tables

Former Member — Thu, 25 Jan 2007 05:42:12 GMT

Thanks for the information.

can u explain me abt hashed tables? i dnt have any idea abt this...

how hash tables can be replaced with internal tables? and when it is better to use these?

can u please give me some examples?

Thanks,

Vijaya.

Re: Internal Tables

Former Member — Thu, 25 Jan 2007 06:47:19 GMT

Hi,

Internal table can be of many types..say standard, hashed, sorted etc..

main diff between standard and hashed is..::

A standard table type of internal table increases the size as and when the data (or records) increases...

But an hash table initially provides a large memory sufficient for lot of data ..say a lakh records..

When the reords go more than lakh, it provides memory for another lakh records..

Means that memory allocation will be in terms of a count...

But , point to be noted is , use hash tables when u r sure that the record count is high.. If not memory space is wasted..

Thanks

Rajiv..

Re: Internal Tables

Former Member — Thu, 25 Jan 2007 07:35:34 GMT

yes i have to store more that 20 lack records in my internal table.

as of now i am declaring all my internal tables as:

data: itab type standard table of "structure name"/"table name" with header line.

now instead how should i declare a hashed table?

is it jus change in the internal table declration or something else also? if yes please tell me where all i need do changes?

and one more question is will it improve my performance in terms of data loading?(please mention reasons for yes/no)

and is there any chance of dump like "cannot extend the internal table"?

Thanks a lot,

Vijaya.

Re: Internal Tables

christian_wohlfahrt — Thu, 25 Jan 2007 08:36:31 GMT

Hi Vijaya!

Usually not the numbers of entries, but the data amount is the problem. So just count the line size of your internal table (e.g. MATNR = CHAR18 -> 18 bytes in normal, 36 bytes in unicode systems). Then multiply by 2 million -> you have your expected memory consumption.

Today's system defaults are set to 2GB as maximum per job - but I would plan my program just with 500 MB as maximun: if there are other jobs running, the theoretical border might already out of reach. Also it's possible to use already the harddisk for swapping much earlier -> bad performance, even if the job will not dump.

By the way: If counting is to difficult, use the debugger. In the new debugger tables are shown like it_data[0x10(20)] which means: 0 entries with 10 fields and 20 bytes (here I had 10 char1 flag-fields).

In case your table would be to big, think about storing names in different tables and read them only for the output -> you store the big fields only once, not x-times in the big table. Or you have to split the work into packages.

Regards,

Christian

Re: Internal Tables

Former Member — Thu, 25 Jan 2007 09:26:13 GMT

Also instead of using the statement REFRESH, use the statement FREE. This will release the memory back to the system.

Re: Internal Tables

valter_oliveira — Thu, 25 Jan 2007 11:53:02 GMT

Hi Vijaya,

About the Hashed tables issue.

First, an hashed table, is a kind of internal table which is used when you have records where you can completly speciffy it's key. It's an internal table where you cannot use the LOOP statement, only READ .. WITH TABLE KEY.

It's most advantage is the performance (the access to it is imediate and bigger the table, bigger the advantage! -

you will notice!!!). Remeber you cannot duplicate it's key. If you do it, you'll het a short dump.

I usually use hashed tables in situations like this. Imagine you have a simple report with 4 colums (DOCUMENT-ITEM-MATERIAL-MATERIAL DESCRIPTION). You can fill an hashed table with the materials and the descriptions like this,

TYPES: BEGIN OF ty_mat,

matnr LIKE mara-matnr,

maktx LIKE makt-maktx,

END OF ty_mat.

DATA: it_mat TYPE HASHED TABLE OF ty_mat

WITH UNIQUE KEY matnr,

wa_mat TYPE ty_mat.

....

SELECT matnr maktx FROM makt

INTO TABLE it_mat WHERE spras EQ 'EN'.

SELECT vbeln posnr matnr FROM VBAP INTO it_items .......

.....

LOOP AT it_items INTO wa_items.

READ TABLE it_mat INTO wa_mat

WITH TABLE KEY matnr = wa_items-matnr.

ENDLOOP.

This will avoid you to duplicade selects for the description for the same material. Imagine you have 2000 documents with only 2 different materials.

I really advise you to use hashed tables anytime it's possible.

Best regards.

Valter Olveira.