Return a standard Table from a method

[former_member10945]

Can someone explain to me WHY i have to create a data dictionary type just so I can return an SAP defined table from a method call?

<b>Example:</b>

methods getT100Table
    returning
      value(t100List) type T100 .

I want to create a public method in a class that a bunch of other classes use. I want that method in that class to return a table of type T100. This is an SAP defined, delivered, standard table. If you attempt to return a table of this type from a method call the complier complains that " "[parameterName]" is not an internal table - the "OCCURS n" specification is missing"

Why do I have to pollute my data dictionary with unnecessary types just to use ABAPOO?

I know you can pass a generic table type and such, I know HOW to get around this I want to know why I should have to.

[Former Member]

Hi Daniel,

Even though T100 is a table in SAP, it still represents both a structure and a table. So when you say type T100, you are only referring to it as a structure rather than a table. You have to tell the compiler both the structure(T100) and how you want to use it(as a table or a string of structure T100).

[sergey_korolev]

Hi Daniel,

Just to add to a nice explanation of Srinivas, I could say that defining your types in dictionary is not a pollution, it is just a good development practice.

[former_member10945]

Srinivas,

So how can i force the compiler to look at the parameter t100List as a table instead of a structure? Why isnt there a "type table of" in the drop down when you add a new parameter?

[former_member10945]

Sergei,

I would agree with you that it is a good practice to have a data dictionary, however in this case the type is already defined in the dictionary, and you are making an extra type that has the same meaning and serving value only to appease the compiler.

That’s why i view it as a pollution you haven't create a new type, just expressed an existing one slightly differently. Keep in mind you can return T100 just fine in a function module using the "tables" area.

Would it make sense to have to define a new string type in the data dictionary just because you wanted to use it as a returning parameter in a method?

[sergey_korolev]

There is an ambiguity in ABAP concerning tables. Inspite of that the transparent table is a real table consisting of rows, ABAP compiler treats it as a structured type (just like a structure). And to tell the compiler that in FM interface you want it to be treat as an internal table you must explicitly place it in the ugly TABLES section. It's ugly because you cannot say if one of the TABLES parameter is importing or exporting or changing. You can only understand which is which by browsing FM source code. By the way it could be a potential reason for bugs difficult to catch. With introducing table types the situation became more symmetric (if this is the word). Even in FM you can define table parameters in IMPORTING, EXPORTING or CHANGING. And in OO you have more accurate sintax control. Alas, it costs additional entry in the dictionary (not very much, I gues ).

[former_member10945]

I guess my displeasure with the situation stems from the fact that the new, welcome, syntax control has not been fully rolled into existing tables in the system --- so for now I’m stuck copying from one type of structure to another, which seems very silly to me. Maybe there should be a tool to convert existing items directly on the system. If you could simply replace the current object with one defined as a Table Type with a Row Structure this problem would not exist. Your FMs would still work correctly and so would anything new you write in OO.

Thanks guess I’m stuck doing unnecessary labor.

[sergey_korolev]

Wait, wait! Why do you copy structures? Could you provide some more details?

[former_member10945]

Not really a copy, guess i should have picked my words more carefully:

1) Create a NEW Data Type (ZT100) of type: Table Type.

2) Set ZT100's Line Type to T100.

So it is not really a "copy" but im still creating the exact same structure to hold data as I had before, just with a differnent name and express slightly differently in the system.

[sergey_korolev]

Oh, I see.