For me TABLES are not obsolete (*), the only rule is No table work areas except for classic dynpros, and yes TABLES * is obsolete, and TABLES are forbidden in classes (***)
But for me the rule is always No table work areas except for classic dynpros
In 7.40 documentation there is yet a MUST to use TABLES:
When dynpro fields are defined with reference to flat structures in ABAP Dictionary, the global data objects with the same name of the ABAP program must be declared with the statement TABLES as interface work area. Otherwise, there will be no data transport.
So either:
- code TABLES statement in global area, and FIELDS statement are optional (**)
- don't code TABLES statements, but then code explicit FIELDS statements in PAI, also global area definition required so a DATA statement (Else syntax error of course
![]()
).
).
Regards,
Raymond
(*) Not more obsolete in any case than classic dynpro themselves 
outdated, old-fashioned, ok?
(**) But we need those (and CHAIN/ENDCHAIN) once we perform some check in PAI and keep field input available in case of error message)
(***) Still waiting to be able to [easily] create a dynpro in a class, and removing those function group associated to many classes and so also with some BAdI