Has 'Tables' parameters become obsolete in function modules?

[Former Member]

Hi,

On the one hand, I read in an ABAP programming guide that using 'Tables' parameter in function module interface has become obsolete. Instead, one should use the importing and exporting parameters..

On the other hand, I am trying to create an RFC to which several internal tables will be passed. If I try to add a parameter to the importing tab of the RFC function module, on doing a syntax check, I get an information message that says that the performance may be reduced and instead I should use the Tables parameter.

Due to this contradiction, I am confused whether to use importing parameters or tables parameters.

Can anyone help please.

Thank you.

[Former Member]

Hi SAPien,

Yes, the tables parameter has become obsolote. Instead use changing parameters to pass your tables.

Much Regards,

Amuktha.

[Former Member]

Hi Amuktha,

When I use changing parameter and do a syntax check, I get an information message, an extract of whose long text is pased below. Any idea?

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

The parameter contains a data type that, in the external system, can lead to a high memory consumption and poorer performance. Affected by this are parameters in IMPORT, EXPORT, and CHANGING parameters that use "deep, nested" (that is, type 2) data types.

Remember also that such data types can cause a large load on the network since they can contain high data volumes and are not compressed in the selected definition during transfer.

You can avoid possible disadvantages if you use the TABLES parameter instead. In this case, conversions at the interface may be possible. These are described below. A flat structure refers to a structure that contains only fields of the data types ACCP, CHAR, CLNT, CUKY, CURR, DATS, DEC, FLTP, INT1, INT2, INT4,LANG, NUMC, PREC, QUAN, RAW, TIMS, or UNIT.

[Former Member]

Hi SAPien,

Try using changing parameters and see if you still geting that message.But the best way to avoid tables parameters is to use changing.

Much Regards,

Amuktha.

[Sm1tje]

Why is using "Changing" parameters the best way? Why not just use the "Exporting parameter" to replace the TABLES?

[Former Member]

Yes , Tables parameter is obsolete in Function modules now.

You can use table or structure or variable in import as well as Export parameters or in Changing parameters too.

Edited by: vijetasap on May 15, 2009 11:49 AM

[Former Member]

Hi Vijetasap,

The problem is that when I use importing/exporting/changing parameters, I get an information message which says that the performance may be reduced.

[Sm1tje]

But this is just an information message which you can "ignore". It is just a reminder that you should be aware that performance CAN be reduced.

This message is not displayed for TABLES, but the performance issue will also apply this parameter.

[Former Member]

Hi,

This is true that tables parameter has become obsolete, and this is also true that if you mention them in importing or exporting parameters for RFC FM will hit on performance and it is also a known fact that you cannot use changing parameters for RFC function modules...

so I would suggest that for creating RFC use tables parameter instead of going for any other option so that the performance does not hit, and if you are creating a normal FM then try to avoid tables parameter.

Regards,

Siddarth

[Former Member]

Hi Micky,

Yes it is just an information message and technically speaking it can be ignored. The point is that the information given by the message is important as it talks about performance which is an important aspect of coding.

Why do u say that the message is just not displayed for Tables parameter but the performance problem will still persist when the information message itself suggests that a loss in performance can be avoided by using Tables parameter.

[Former Member]

Hi "sap developer" (aren't we all "sap developers" around here?),

The warning message is indicating that with import/export parameters it is possible to have deep structured tables, whereas the TABLES parameters only allow flat structures.  The performance will be the same regardless of import/export/tables parameter type; all that matters is how many rows and how much data per row.  Since TABLES parameters cannot be deep-structured, SAP sees less risk if you use them.  But so long as you are aware of the risks of deep-structures you should use import/export/changing and specify a table type.

Jim

[Former Member]

Jim Tasker wrote:

Hi "sap developer" (aren't we all "sap developers" around here?),

Well, given the date of the original thread, possibly not.

Rob

[Former Member]

When I used tables parameter in an RFC function module, it gave an error on the destination system. So, tables parameters can't be used for sure atleast in RFCs now.

[Former Member]

Hi All,

I'm also in confusion state , whether to use internal table as import/export parameter or under tables section.

ofcourse its a silly question but need clarification

Regards,

Lokes.

[former_member218500]

Hi Lokeswar,

     Actually it is not recommended to use Tables, since it consumes high memory. But still it doesn't mean you can't use it. Worst case, you can still use it. Make sure you declare as "LIKE" instead of "TYPE". Press Enter twice, if you get warning message.

But we do have alternate solution for it, Create an exporting/changing parameter of the Table type/ztable.

If you are using the structure, just create a Table type of it and can be used in import/export parameters.

Cheers!!!!!

[matt]

To close this once and for all.

For normal function modules - use importing/exporting parameters which are table types.

For RFC enabled function modules - you can safely use TABLES parameters and ignore the warning.

Thread locked.