Start of Content Area

Background documentation Avoiding Problem Cases  Locate the document in its SAP Library 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 means that every field used in every section of code has to be named explicitly. 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 Example 1:

The KNC1 table contains the UM01U, UM02U and UM03U fields. These fields contain the monthly sales figures for the first three months of a year. An additional field, Q1, is to be used for the sales figure for the first quarter. This field calculates the sum of the other three fields with an external Perform.

PERFORM QUARTAL1(pppppppp) USING Q1.

The KNC1-UM01U, KNC1-UM02U and KNC1-UM03U fields are accessed via the common memory for the KNC1 table in the query report and in the program pppppppp that gets called. However, it is not evident from the code fragment above that these fields are actually required. Therefore this code fragment needs to be modified as follows:

PERFORM QUARTAL1(pppppppp) USING Q1.

FIELDS: KNC1-UM01U, KNC1-UM02U, KNC1-UM03U.

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 Example 2:

The additional fields F1 and F2 are defined in the following code:

F1: F1 = TAB-FELD. "TAB-FELD 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 kind of indirect reference is automatically resolved 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.

End of Content Area