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:
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?!
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. ;-(
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.
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.
Oh ATC, you become the very thing you swore to destroy (i.e. a buggy program)! 🙂
Thanks for sharing, Joachim!