TABLES statement in report program

[Former Member]

Hi,

Is there any performance issue in using TABLES statement in report program? Because I have got an review point from QA insisting me to avoid TABLES statement. Is it recommended by SAP to avoid TABLES statement in report program?

Thanks in advance.

Regards,

Balaji Viswanath.

[Former Member]

Balaji,

If you use TABLE statement it will provide the work area of the given table.

EX: Decalre any fields of table in slection scereen

without declarin g the tabel name in TAble statement.It will give error.

This will give error.

SELECT-OPTIONS : s_matnr LIKE MARA-matnr.

This will work.

TABLES: mara.

SELECT-OPTIONS : s_matnr LIKE MARA-matnr.

It means it will occupy some area.

Don't forget to reward if useful.

[Former Member]

Hi,

If you want a workarea for the tables which you are using with in the Program then use the TABLES statment otherwise do not use these statments, if you are nor using the workarea then you are wating some memory of the SAP using these TABLES statment

Regards

Sudheer

[Former Member]

There are no performance issues related to using the TABLES statement; however, it is not allowed in an OOP context. It's reccommended to use other constructs (like TYPE).

Rob

[Former Member]

As Rob pointed out, it's a standards issue (even if you don't use ABAP objects you still want to avoid using it)

If you do an F1 lookup on the TABLES command

"You should only use the TABLES statement in an ABAP program where it is absolutely necessary, namely to transport fields with an ABAP Dictionary reference between screens and an ABAP program, or to transport data between a logical database and an executable program."

You should only use the TABLES command for select-options or dialog programming.

[Former Member]

I've found a curious use-case for TABLES statement .

Although important while using selection-screen , it is a waste of memory otherwise. But recently I enocuntered an error while moving a TR to QA . In the import log it was giving a syntax error at a particular line in the code , which was a SELECT query . But if a program has syntax error it shouldn't get activated & hence not assigned to a TR . So , it took me some to understand that our QA & DEV system are out of sync & thus the dictionary object BSET I was using in my select statement somehow was different in QA & thus it needed to be loaded in program memory to be transported .

So I assigned BSET to TABLES statement & the program was transferred successfully . I'm still not sure how it worked but it happened regardless. Does anyone have a better understanding for this ?

[Sandra_Rossi]

Please ask a new question and add a link to this page. People here are all "former members", and the discussion is 12 years old.