Avoiding Problem Cases
Use
If an InfoSet contains sections of code that lead to problems, a warning is output each time the InfoSet is generated. You then have to check whether any of the example cases described below have occurred and correct the InfoSet accordingly.
The freedom to use any ABAP language construct at any point in a section of code means that it is possible to access fields without explicitly referring to these fields (field symbols, external Perform, DO... VARYING, ADD... THEN... UNTIL, and so on).
In order to ensure that query reports can be generated without errors, it is essential that all fields accessed can be determined in EVERY section of code (additional fields, GET / GET LATE / record processing). This requires that each field used is also specified in this piece of coding. If a section of code contains ABAP statements that access certain fields implicitly and that are not in the reference list, then you have to use the ABAP FIELDS statement in the code to ensure that all database fields, table fields and additional fields that are used are named explicitly.
In some cases, you can use the following statement in the coding: FIELDS TAB, where TAB is a database table or an additional table.
This statement has the effect of using all the fields of the TAB table in the query report. Note that this means that the access to the TAB table is no longer optimized and that you can therefore expect a considerable loss in performance when processing queries.
If you follow the advice given here on maintaining an InfoSet carefully, you will always be able to generate complete reference lists. However, the system cannot check whether you have followed the advice in this documentation, so the possibility of reference lists being incomplete cannot be ruled out. If a reference list is incomplete for a query report, this could lead to fields that are needed not being read from the database and therefore always retaining their initial values.