Show TOC

Avoiding Problem CasesLocate this document in the navigation structure


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.


Example 1:

Suppose the table KNC1 contains the fields UM01U, UM02U and UM03U with the sales for the first three months of a year. An additional field Q1 that should contain the business volume for the first quarter computes the sum of these three fields using an external perform.


Fields KNC1-UM01U, KNC1-UM02U and KNC1-UM03U are accessed with the common storage area for table KNC1 in the query report and in the called program pppppppp. You cannot see in the given coding that the specified fields are required. You therefore have to change this piece of coding as follows:



It is important to ensure that you have name all required fields explicitly in every section of code. This is because each section of code is included in the query report only if it is really used, and therefore it has to be clear from the individual sections of code, which fields are needed in that particular section of code.

Note also that only those fields that are directly used in a section of code need to be named there.


Example 2:

The additional fields F1 and F2 are defined with the following coding:

F1: F1 = TAB FIELD. "TAB FIELD is a database field

F2: F2 = F1 + 2.

Even though F2 indirectly accesses TAB-FELD, it is not necessary to list TAB-FELD in the code of F2 as being one of the fields used. This is because the processing of these indirect references is performed automatically when the InfoSet is generated. The sections of code for both additional fields is therefore correct exactly as given above.

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.