11-05-2013 10:27 PM
I had asked this once and they deleted it with the reason of FAQ but I looked through the FAQ and did not see anything in there that answered this question so I will ask again but shorten it up. TO ANY MODERATORS THAT FEEL THIS SHOULD BE DELETED: If I am wrong and this is in an FAQ somewhere, please oblige me and point me to the FAQ that answers this question before you delete it..
Consider the following statement from the Help files when looking at the help for DATA:
The most important difference compared with the statement TYPES is that a data type defined using DATA (and not derived from an existing type) is available only as a property of the declared data object and is not independent. This kind
of data type is bound to its data object.
I am looking for a plain explanation on why there are two ways to create a structure, TYPES and DATA. Why not just one way? Now consider the following pieces of code:
Example 1:
TYPES: BEGIN OF My_Stuff,
Field1(15),
Field2(15),
END OF My_Stuff.
Example 2:
DATA: BEGIN OF My_Stuff,
Field1(15),
Field2(15),
END OF My_Stuff.
Can someone fill in the blank on either of the two following statements:
If you create the structure using example 1, you would be able to _________________ but would not be able to ___________________.
OR
If you create the structure using example 2, you would be able to _________________ but would not be able to ___________________.
Also, I know things defined with the DATA statement I understand are created in memory but why do I care about this? I can still reference fields in either one so why would this be a benefit or not? Just for performance?
11-05-2013 10:44 PM
Hi Richard,
if you create the structure using example 1, you have less memory consumption when you have a table and a field-symbols structure.
TYPES: BEGIN OF ts_my_stuff,
Field1(15),
Field2(15),
END OF ts_my_stuff.
TYPES: tt_my_stuff TYPE STANDARD TABLE OF ts_my_stuff.
DATA lt_my_stuff TYPE tt_my_stuff.
FIELD-SYMBOLS <fs_my_stuff> TYPE tt_my_stuff.
LOOP AT lt_my_stuff ASSIGNING <fs_my_stuff>.
ENDLOOP.
Next to this. There are no big advantages, but I would prefer the TYPES so I can attach it to any variable at all times.
Good news that In 7.40 with the inline declaration, you have less worry's about this anymore.
Best,
Sander
11-05-2013 10:44 PM
Hi Richard,
if you create the structure using example 1, you have less memory consumption when you have a table and a field-symbols structure.
TYPES: BEGIN OF ts_my_stuff,
Field1(15),
Field2(15),
END OF ts_my_stuff.
TYPES: tt_my_stuff TYPE STANDARD TABLE OF ts_my_stuff.
DATA lt_my_stuff TYPE tt_my_stuff.
FIELD-SYMBOLS <fs_my_stuff> TYPE tt_my_stuff.
LOOP AT lt_my_stuff ASSIGNING <fs_my_stuff>.
ENDLOOP.
Next to this. There are no big advantages, but I would prefer the TYPES so I can attach it to any variable at all times.
Good news that In 7.40 with the inline declaration, you have less worry's about this anymore.
Best,
Sander
11-05-2013 11:41 PM
Thank you. That makes sense in just the fact that "If defined under Types you can assign that structure to other variables". I can see using that part of it when creating something where I needed to compare things in multiple tables with an identical structure. If done with example 2 Id have to write it out twice. Thank you again.