ATC Check: Explicit SORT statement required

[manishgupta03]

Hi,

I have noticed that when we select data from second table(say ITAB2) based on first table(say ITAB1) using FOR ALL ENTRIES, without explicitly specifying the SORT statement on the first table (eg: SORT itab1 by key fields), the ATC check gives error that the two tables can be JOINED instead of individual selects. If I write an explicit SORT statement on ITAB1, the error goes away.

This happens if we define the ITAB1 as SORTED TABLE OF or apply the ORDER BY clause based on the primary key while fetching data.

Does it mean that ATC looks for an explicit SORT statement and does not consider that table is SORTED using a different technique?

Regards,

Manish

[Sandra_Rossi]

Is it a sorted table on the primary key? Do you use ORDER BY with FOR ALL ENTRIES? (there used to be lots of issues until recently, cf SAP notes)

Either it's not exactly what you said, or ATC prioritizes the recommendation of joining the two database tables before checking the primary index, or it's a bug in ATC.

But without the exact code concerned, and without the exact message, it's difficult to say.

[manishgupta03]

Hi Sandra,

Here is the code for various scenarios:

1. No SORT statement anywhere:
If I do not use the SORT statement on lt_A501, in ATC check, it says that I should be joining these two tables (A501 and KONP). As A501 is a buffered table, I am not joining it with KONP, even if I do, the current ATC error goes away, but another one comes up which says" Buffered table in a JOIN".

SELECT matnr, knumh

        FROM  a501
       WHERE  kappl =  'V'
        AND   kschl = 'ZMGC'
         AND  zzbuy =  'G0050'
         AND  matnr IN @lt_product_range
          AND datab LE @sy-datum
          AND datbi GE @sy-datum
        INTO TABLE @DATA(lt_a501).

      IF lt_a501 IS NOT INITIAL.
        " Get only the active condition records
        SELECT knumh, kbetr
         FROM konp
         FOR ALL ENTRIES IN @lt_a501
         WHERE knumh = @lt_a501-knumh
          AND  loevm_ko = ' '
         INTO TABLE @DATA(lt_konp).

2. Explicit SORT statement added :
if I add the explicit SORT statement on lt_A501 based on KNUMH, the ATC error goes away.

      SELECT matnr, knumh
        FROM  a501
       WHERE  kappl =  'V'
        AND   kschl = 'ZMGC'
         AND  zzbuy =  'G0050'
         AND  matnr IN @lt_product_range
          AND datab LE @sy-datum
          AND datbi GE @sy-datum
        INTO TABLE @DATA(lt_a501).

      IF lt_a501 IS NOT INITIAL.
        SORT lt_a501 BY knumh.
        " Get only the active condition records
        SELECT knumh, kbetr
         FROM konp
         FOR ALL ENTRIES IN @lt_a501
         WHERE knumh = @lt_a501-knumh
          AND  loevm_ko = ' '
         INTO TABLE @DATA(lt_konp).

3. SORT using ORDER BY:
And if I specify ORDER by KNUMH in the first query itself, ATC error again comes back

      " get data from condition table for the govt price buying grp
      SELECT matnr, knumh
        FROM  a501
       WHERE  kappl =  'V'
        AND   kschl = 'ZMGC'
         AND  zzbuy =  'G0050'
         AND  matnr IN @lt_product_range
          AND datab LE @sy-datum
          AND datbi GE @sy-datum
        ORDER BY knumh
        INTO TABLE @DATA(lt_a501).

      IF lt_a501 IS NOT INITIAL.
        " Get only the active condition records
        SELECT knumh, kbetr
         FROM konp
         FOR ALL ENTRIES IN @lt_a501
         WHERE knumh = @lt_a501-knumh
          AND  loevm_ko = ' '
         INTO TABLE @DATA(lt_konp).

[FredericGirod]

(Use Answer to propose a solution & Comment to add information or react on a proposal)

did you try to add BYPASSING BUFFER option in the INNER JOIN ?

[gasparerdelyi]

Hello Manish,

ATC is a static code analysis tool. It works solely on source code, not in runtime and focuses on the most common weaknesses of the code. Hence it has a limited power to unfold complexity of the code. It is also not welcome to have tons of false positive findings..

I would assume that an explicit SORT means for ATC something like the following: too complex scenario, does not worth to investigate any more, the developer must know what she or he is doing...