Internal Table

[Former Member]

Hi All,

I have small doubts on internal tables...

1 Which is better method to create a internal table

using and How

1. Occurs statement

2. type table of <structurename>

pls any one explain me in detail..

2. We can create internal tables with header line or with work area. Which one is better and why?

Thanking u in advance

Singh

[Former Member]

1. TYPE TABLE of is better.

2. Explicit work area is better.

For both the reason is same. OO ABAP does not work with OCCURS parameter or default header line.

It needs a STANDARD / SORTED / HASHED table type with a explicti work area or a field symbol.

Regards,

Ravi

Note : Please mark all the helpful answers

[Former Member]

u get answer by ravi...

for completw refrense refer...

http://help.sap.com/saphelp_nw04/helpdata/en/fc/eb3646358411d1829f0000e829fbfe/content.htm

[Former Member]

hi raju,

Standard way is.......

DATA: BEGIN OF <itab> OCCURS <n>,

...

<fi> ...,

...

END OF <itab>.

In this way u did not need to specify work area.

If u want to include whole structure of a table then u have to use.....for example mara

then

data: begin of itab,

include structure mara.

data:end of itab.

Regards

Abhishek

[Former Member]

Hi raju,

1.

Which is better method to create a internal table

using and How

I would personallly prefer

OCCURS concept.

(bcos the syntax is simple & easy,

and no need to do in 2 steps, ie. first define types, and then define data for the same)

2.We can create internal tables with header line or with work area. Which one is better and why?

As per documentataion,

table with header line is a little slower than

table with work area concept.

But, however,

We do not write all programs,

which processs lakhs of records everytime,

so, i personally prefer

to use table with header line,

bcos the syntax is simple and cleaner.

regards,

amit m.

[Former Member]

Hi,

check the following link

http://help.sap.com/saphelp_nw2004s/helpdata/en/fc/eb3646358411d1829f0000e829fbfe/frameset.htm

hope this helps.

regards,

Kinshuk

[Former Member]

Hi Raju,

The best way to create an Internal table

1)Declare a structure using <b>TYPES</b>

TYPES : BEGIN OF str_mara,
        matnr TYPE mara-matnr,
        mtart TYPE mara-mtart,
        END OF str_mara.

2)Decalre the Internal Table referring the structure created.

DATA : it_mara TYPE STANDARD TABLE OF str_mara,  "Internal Table
       wa_mara TYPE str_mara.                    "Work Area 

<b>Note:</b>

1)Dont use header line, instead use work areas(Int table declaration with header line is <b>forbidden</b> in <b>ABAP Objects</b> so is the case with <i>Occurs 0</i>).

<a href="https://sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/5ac31178-0701-0010-469a-b4d7fa2721ca">Guide to Obsolete Abap Constructs</a>

Regards,

Arun Sambargi.

[abdul_hakim]

hi

don't use OCCURS addition while creating internal table.

Internal tables with header lines are oldest form of internal table and it wont be

allowed in OO Context.

So i would advice you to create internal table without header.

It also gives you clear understanding of what you are doing in your program..

Oldform:

data: begin of itab occurs 0,

col1 type i,

col2 type i,

end of itab.

new form:

data: begin of wa,

col1 type i,

col2 type i,

end of wa.

data itab like table of wa.

Cheers,

Abdul Hakim

[aris_hidalgo]

Hi Raju,

Please take a look the code below. It is better to declare a structure then an itab for that structure and a seperate work area or field-symbols. Because when you want to program using ABAP Objects, it will not allow you to use header lines and the statement OCCURS 0.

----

---

• Structures *

----

---

TYPES: BEGIN OF t_final,

bukrs LIKE bsik-bukrs, "Company Code

lifnr LIKE bsik-lifnr, "Account number of vendor or creditor

hkont LIKE bsik-hkont, "General ledger account

belnr LIKE bsik-belnr, "Accounting document number

gjahr LIKE bsik-gjahr, "Fiscal year

shkzg LIKE bsik-shkzg, "Debit/credit indicator

dmbtr LIKE bsik-dmbtr, "Amount in local currency

sgtxt LIKE bsik-sgtxt, "Item Text

buzei LIKE bsik-buzei, "Number of Line Item

budat LIKE bkpf-budat, "Posting date in the document

bldat LIKE bkpf-bldat, "Document date in document

xblnr LIKE bkpf-xblnr, "Reference document number

bktxt LIKE bkpf-bktxt, "Document header text

name1 LIKE lfa1-name1, "Vendor name

s_dat(10) TYPE c, "Start date(from long text)

e_dat(10) TYPE c, "End date(from long text)

amount1 LIKE bsik-dmbtr, "If 30 days and below

amount2 LIKE bsik-dmbtr, "If > 30 and < 60 days

amount3 LIKE bsik-dmbtr, "If > 60 and < 90 days

amount4 LIKE bsik-dmbtr, "If > 90 and < 120 days

amount5 LIKE bsik-dmbtr, "If > 120 and < 180 days

amount6 LIKE bsik-dmbtr, "If > 180 days

END OF t_final.

----

---

• Internal tables *

----

---

DATA: it_final TYPE STANDARD TABLE OF t_final

*field-symbols

FIELD-SYMBOLS: <fs_final> LIKE LINE OF it_final.

Hope this helps...

P.S. Please award points for useful answers.

[Former Member]

hi,

Internal Tables:

Cannot Use OCCURS with Declarative Statements:

In ABAP Objects, you cannot define internal tables using the OCCURS addition in the TYPES or DATA statements (or any other declarative statement).

In ABAP Objects, the following statements cause an error message:

TYPES|DATA: BEGIN OF itab OCCURS n,

...

fi ...,

...

END OF itab.

and

TYPES|DATA itab TYPE|LIKE line_type OCCURS n.

Correct syntax:

TYPES|DATA: BEGIN OF line_type,

...

fi ...,

...

END OF line_type.

TYPES itab TYPE|LIKE STANDARD TABLE OF line_type

WITH NON-UNIQUE DEFAULT KEY

[INITIAL SIZE n].

DATA itab TYPE|LIKE [STANDARD] TABLE OF line_type

[INITIAL SIZE n].

Cause:

TYPE|LIKE TABLE OF, the new additions of the DATA and TYPES statements, make the OCCURS addition superfluous in table declarations. If necessary, you can define the initial main memory requirement using the INITIAL SIZE addition.

Note:

The system automatically updates the short form

DATA itab TYPE|LIKE TABLE of line_type.

to

DATA itab TYPE|LIKE STANDARD TABLE OF line_type

WITH NON-UNIQUE DEFAULT KEY

INITIAL SIZE 0.

so that you can use the former.

The system automatically updates the short form

TYPES itab TYPE|LIKE STANDARD TABLE of line_type.

to

TYPES itab TYPE|LIKE STANDARD TABLE of line_type

INITIAL SIZE 0.

and defines a standard table type with a generic key that can be used to type interface parameters and field symbols.

Cannot Use Headers in Tables:

In ABAP Objects, you can only declare tables without headers.

In ABAP Objects, the following statement causes an error message:

DATA itab TYPE|LIKE TABLE OF ... WITH HEADER LINE.

Correct syntax:

DATA: itab TYPE|LIKE TABLE OF ... ,

wa LIKE LINE OF itab.

Cause:

Depending on the statement, the system may access tables with a header either by accessing the table body, or by accessing the header itself. The table name should signify the table unambiguously. This makes programs easier to read. Tables with headers do not offer any performance advantages.

Note:

When you call external procedures (subroutines and function modules) that are contained in the parameter interface TABLES parameter, be aware that this TABLES parameter always contains both a table body and a header. When a table without a header is transferred, the header of the TABLES parameter remains blank. When calling these procedres in methods, you must check to see whether the procedure expects to receive and evaluate the header. If necessary, adapt or rewrite the procedure. Method interfaces do not have TABLESparameters.

Incompatible Work Area when Processing Control Levels:

The work area must be compatible with the table line type when you process control levels in an internal table in ABAP Objects.

In ABAP Objects, the following statement causes an error message:

DATA: itab LIKE TABLE OF line,

wa(255) TYPE x.

SORT itab by col1.

LOOP AT itab INTO wa.

AT NEW col1.

ENDAT.

ENDLOOP.

Correct syntax:

DATA: itab LIKE TABLE OF line,

wa LIKE LINE OF itab.

SORT itab by col1.

LOOP AT itab INTO wa.

AT NEW col1.

ENDAT.

ENDLOOP.

Cause:

Control level processing is based on the line structure of the internal table. The system evaluates the work area when it wants to change the control level, which means that the work are must have the same structure as the line of the table.

Cannot Declare a Superfluous Work Area:

In ABAP Objects, you cannot declare a work area as an addition to the READ TABLE statement, if you are also using the TRANSPORTING NO FIELDS addition.

In ABAP Objects, the following statement causes an error message:

READ TABLE itab INDEX i INTO wa TRANSPORTING NO FIELDS.

Correct syntax:

READ TABLE itab INDEX i TRANSPORTING NO FIELDS.

Cause:

Declaring INTO wa is superfluous. The work area has no effect in the statement.