internal table within a structure

[kimmo_sirpoma]

I found a strange situation when in a program defining an internal structure that has as internal table as an element.

For your convenience I use here the same examples than in SAP Help http://help.sap.com/saphelp_nw04/helpdata/en/fc/eb366d358411d1829f0000e829fbfe/content.htm with slighly edited piece of code.

Depending how you define your internal table that is included in the structure you get syntax check error.

Implement this piece of code and you will see the difference (apply the two commented lines)

TYPES: BEGIN OF LINE,
COLUMN1 TYPE I,
COLUMN2 TYPE I,
COLUMN3 TYPE I,
END OF LINE.

*This version of typing works
TYPES VECTOR TYPE STANDARD TABLE OF LINE WITH DEFAULT KEY.
TYPES ITAB TYPE STANDARD TABLE OF LINE WITH DEFAULT KEY.
*this version of typing will cause syntax check error for element VECTOR in type DEEPLINE. Uncomment to see the difference
*TYPES VECTOR TYPE STANDARD TABLE OF LINE.
*TYPES ITAB TYPE STANDARD TABLE OF LINE.

TYPES: BEGIN OF DEEPLINE,
FIELD TYPE C,
TABLE1 TYPE VECTOR,
TABLE2 TYPE ITAB,
END OF DEEPLINE.

TYPES: DEEPTABLE TYPE STANDARD TABLE OF DEEPLINE
WITH DEFAULT KEY.

data: MYDEEPTABLE type deepline.

****************

If you DON'T use the "WITH DEFAULT KEY" (or any other key) notation you will get syntax error at line TABLE1 TYPE VECTOR: "VECTOR has generic type. Use of this type only possible for typing fields symbols and formal parameters".

So what's the difference regarding 'generic type' issue whether to use a KEY notation or not? How come use of KEY makes the table non-generic thus passes syntax check?

We use the latest SAP kernel version of a netweaver instance of ECC 6.0 (without any EHP), but SP-level is quite low. But I assume it is the kernel that is more important regarding syntax checking.

Please note, I don't need advice how to define a structure that has internal table. In fact the above sample is a solution.

But I wanted to hear your opinion if there is an error in syntax check procedures here?

At least I would find it very handy to define deep structures with tables and not having KEY nor SORTED/HASHED notation for the internal table part.

br: Kimmo

[SuhaSaha]

Hello Kimmo,

The answer to your dilemma lies in SAP documentation itself

Defining Structures using TYPES - BEGIN OF states -

If a component is created as a table type, this type cannot be generic.

Defining KEYS for table type states -

An internal table that has no table key or an incomplete table key is generic with respect to the table key. A table type of this nature can be used only for typing formal parameters or field symbols.

How come use of KEY makes the table non-generic thus passes syntax check?

When you do not specify the key the table-type generic is w.r.t the key. So when you use the KEY addition to define the key, in your case the DEFAULT KEY, the table-type is no longer generic and passes the syntax check

But I wanted to hear your opinion if there is an error in syntax check procedures here?
At least I would find it very handy to define deep structures with tables and not having KEY nor SORTED/HASHED notation for the internal table part.

In your case the compiler is checking what it is supposed to check If you don't want to specify the KEY explicitly you cannot use table types, rather you have to use LIKE <internal table> for defining the deep structure.

TYPES:
 BEGIN OF line,
   column1 TYPE i,
   column2 TYPE i,
   column3 TYPE i,
 END OF line.
 DATA:
 vector  TYPE STANDARD TABLE OF line," WITH DEFAULT KEY,
 itab    TYPE STANDARD TABLE OF line." WITH DEFAULT KEY,
 TYPES:
 BEGIN OF deepline,
    field1 TYPE c,
    table1 LIKE vector,
    table2 LIKE itab,
 END OF deepline,
 deeptable TYPE STANDARD TABLE OF deepline." WITH DEFAULT KEY.
 DATA: mydeeptable TYPE deeptable,
       mydeepstruc TYPE deepline.

Hope this answers your query.

BR,

Suhas

Message was edited by: Suhas Saha

[kimmo_sirpoma]

Saha, thank's for clarification and for the second solution using LIKE.

Still I don't understand why ABAP kernel requires to use non-generic table type when using TYPES. What's the point? Only SAP can tell, I guess. For the ease of understanding creations of deep structures with TYPING, it would be more clear if no such dependencies exists.

But let's hope this discussion was useful for others seaching solutions for defining deep structures. There existed already a couple of threads in SDN, but at least I did not found them useful because most of them suggested using Dictionary structures or INCLUDE command.

I got my answer, but not closing this yet (for a few days and then close and reward) if others want to comment.

br: Kimmo