Application Development 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: 

Types vs Data When Defining Structures

Former Member
0 Kudos

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?

1 ACCEPTED SOLUTION

former_member192854
Active Participant
0 Kudos

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

2 REPLIES 2

former_member192854
Active Participant
0 Kudos

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

0 Kudos

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.