Skip to Content
Personal Insights

Dear ATC, I don’t trust you any more! :-( …e.g. when your search for problematic SELECT * statements

If you follow me around here, you probably notice that I’m digging into ATC right now.

I recently had 2 cases, where ATC would find something, but it would ignore something quite similar, right next to that.

I turned those observations into questions in case you want to have a look:

https://answers.sap.com/questions/13029896/bug-atc-check-to-search-for-unjustified-select-fin.html

https://answers.sap.com/questions/13029094/atc-check-for-s4hana-field-length-extension-materi.html

The one for the ATC-check “Search problematic SELECT * statements” I now boiled down towards its essence in a demo-class, which I can also share.

So, here’s the thing:

I have two selects, and the are quite identical, an they are equally bad in regards to greedieness: The both select all of EKPO while only two of the fields are actually needed.

The ATC-Check “Search problematic SELECT * statements” is to find just these cases. And it does. But only for one of the two:

 

And the only difference I can spot is:

The first select is surrounded by an

LOOP AT t_ekkn INTO gs_ekkn.

and the 2nd one by:

LOOP AT t_ekkn ASSIGNING FIELD-SYMBOL(<l_ekkn>).

(First might be what I find when I go ATC-hunting, the 2nd one might be what I refactor towards).

If you want to play around with it, here’s the full pasteable code:

class ZCL_JRE_ATC_SELECT_STAR definition
  public
  create public .

PUBLIC SECTION.


  METHODS do_wild_selects.

protected section.
PRIVATE SECTION.

  DATA gs_ekpo TYPE ekpo .
  ENDCLASS.



CLASS ZCL_JRE_ATC_SELECT_STAR IMPLEMENTATION.


  METHOD do_wild_selects.


    SELECT ebeln, ebelp
      FROM ekkn
      INTO TABLE @DATA(t_ekkn)
      WHERE aedat = @sy-datlo.


    DATA: gs_ekkn LIKE LINE OF t_ekkn.

    LOOP AT t_ekkn INTO gs_ekkn.

      SELECT SINGLE *
##db_feature_mode[table_len_max1]
        FROM ekpo
        INTO @gs_ekpo
        WHERE retpo = @abap_true "'x'
        AND ebeln = @gs_ekkn-ebeln
        AND ebelp = @gs_ekkn-ebelp
        AND loekz = @abap_false.
      IF sy-subrc = 0.
        WRITE gs_ekpo-menge UNIT gs_ekpo-meins.
      ENDIF.

    ENDLOOP.


    LOOP AT t_ekkn ASSIGNING FIELD-SYMBOL(<l_ekkn>).

      SELECT SINGLE *
##db_feature_mode[table_len_max1]
        FROM ekpo
        INTO @gs_ekpo
        WHERE retpo = @abap_true
        AND ebeln = @<l_ekkn>-ebeln
        AND ebelp = @<l_ekkn>-ebelp
        AND loekz = @abap_false.
      IF sy-subrc = 0.
        WRITE gs_ekpo-menge  UNIT gs_ekpo-meins.
      ENDIF.

    ENDLOOP.

  ENDMETHOD.
ENDCLASS.

So: how to trust ATC, if it only finds some of the bugs?!

best
Joachim

/
4 Comments
You must be Logged on to comment or reply to a post.
  • Hey Joachim,

    we are actually also finding some false positives in ATC from time to time. If you have a S-User, please create an incident in SAP support portal. In most cases SAP fixes the error we report in ATC (and therefore for all SAP customers). Unfortunately some bugfixes are only provided latest releases, which should be S/4HANA and not for NetWeaver based ATC hubs. ;-(

    Cheers,
    Alej

  • The bad part of the story, that ATC has bugs.

    The good part of the story, that tons of ATC fixes are available as sap note (even quite recent ones):

     

    If you don’t find any matching, you can just open a message (another question how much you have to wait or fight with first level support:) ).

    In my previous company when we started to set up ATC we implemented about 20-30 notes and noticed, that we need to implement a couple of them every month to keep everything up to date.

    So I’m not surprised that ATC result is not 100% reliable, but at least it can be always improved via sap notes.

    Best regards,

    Peter

     

    /
    • It’s the Halting Problem all over again. To check code for errors we have to use a program. And there’s no way of guaranteeing that any code is error free.