Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

declaring internal table

Former Member
0 Likes
805

hi all,

heard while creating internal table it is always better to use TYPE than LIKE.

whats the basic differnece?

also heard OCCURS 0 is outdated and not used at all in REAL TIME.

plz explain.

8 REPLIES 8
Read only

RichHeilman
Developer Advocate
Developer Advocate
0 Likes
781

That's right, OCCURS is older syntax and not supported in ABAP Objects. You should declare your internal tables like so.

Types: begin of ttab,
            fld1 type c,
            fld2 type c,
           end of ttab.

data: itab type table of ttab.
data: wa like line of itab.

Regards,

Rich Heilman

Read only

Former Member
0 Likes
781

Hi,

In ABAP Objects environment it is not allowed to use neither the OCCURS senteces, nor to reference dictionary objects using LIKE.

The reason for not using LIKE is to be more in concordance with object's developing standars.

According to SAP, the LIKE statement should only be used to make reference to data objects, while when we use it with dictionary fields, structures, tables, etc.; we are making reference to data types (and not objects). Nevertheless, using the sentence LIKE to reference objects of the program itself is allowed.

As for not using OCCURS, it should be replaced by the sentence TYPE TABLE OF or LIKE TABLE OF (referencing program objects); being this mainly because the sentence OCCURS creates a table with a header line, which should not be used any longer in ABAP Objects. For what I understand this obeys to the tendence of making sentences more clear to read: you must understand that when using header lines, it wasn't very clear when you were making reference to the table and when to header line.

To conclude, these and many other restrictions are caused by the willing to make ABAP evolve into a more object-friendly language.

I hope this was of any help to you.

Regards,

Eduardo.

Read only

Former Member
0 Likes
781

Hi,

TYPES: BEGIN OF ts_t179,

prodh LIKE t179-prodh,

grade(5) TYPE c,

basis_wt(5) TYPE c,

END OF ts_t179.

DATA: gt_t179 TYPE STANDARD TABLE OF ts_t179 INITIAL SIZE 0,

gs_t179 TYPE ts_t179. "Work Area

Sri

Read only

Former Member
0 Likes
781

hi rich, eduardo,sri very very thanx for ur quick reply. i have clearly understood the concept, now.

generally, as far as my knowledge v use OCCURS 0 for assigning memory space to internal table.what should v use now , without OCCURS 0 to allocate memory?

Read only

0 Likes
781

I believe that memory become allocated dynamically, without us doing anything -;)

Greetings,

Blag.

Read only

0 Likes
781

Indeed, we shouldn't do anything anymore. But, if you must specify the initial memory requirements you can do it by using the addition "INITIAL SIZE n " when declaring the table (for example, OCCURS 0 is the same as INITIAL SIZE 0).

Hope this was of any help.

Regards,

Eduardo.

Read only

0 Likes
781

Yeah as you can see in the declation used above INITIAL SIZE 0 will take care of it i guess.

Read only

0 Likes
781

From F1 in INITIAL SIZE:

The value of INITIAL SIZE has no semantic significance except in the case of APPEND SORTED BY. If INITIAL SIZE is not declared, its value is set to 0.

From f1 on occurs:

The OCCURS and INITIAL SIZE additions (hereafter called the OCCURS value), determine the initial number of table lines created. The table is enlarged by the system when necessary. For more details about this, see performance notes for internal tables. The OCCURS value has no semantic meaning apart from an exception with APPEND SORTED BY. If you do not specify the INITIAL SIZE, the system sets the OCCURS value to 0 by default.

If there's any difference between them, I don't see it.

Rob