Why the combination of LOOP AT <itab> WHERE and AT event should be avoided?

[Former Member]

Hi Guys,

I intended to use the combination of LOOP AT <itab> WHERE and AT event in my code as the following.

SORT itab BY a b.
LOOP AT itab INTO wa WHERE a = '2'.
    AT NEW b.
    ...
    ENDAT.
ENDLOOP.

After run the code, I got what I expected(which is good). But only to find there is a explicit statement saying,

So that group level processing can be executed correctly, the following rules should be noted: 
*After LOOP there should be no limiting condition cond specified.

Would you guys help explain why using "limiting condition of LOOP" will mess up with group level processing?

Thanks you so much in advance.

Kevin:)

"The statement block of a LOOP loop can contain control structures for control level processing. The respective control statement is AT. The statements AT and ENDAT define statement blocks that are executed at control breaks. Within these statement blocks, the statement SUM can be specified to total numeric components of a group level. In the case of output behavior result, the same applies as for LOOP AT. 
So that group level processing can be executed correctly, the following rules should be noted: 
*After LOOP there should be no limiting condition cond specified. 
*The internal table must not be modified within the LOOP loop. 
*The work area wa specified in the LOOP statement after the INTO addition must be compatible with the line type of the table. 
*The content of a work area wa specified in the LOOP statement after the INTO addition must not be modified. "

[Former Member]

In your specific case you should be ok. I.e. the online documentation actually says for [loop events AT - ITAB|http://help.sap.com/abapdocu_70/en/ABAPAT_ITAB.htm]:

A restricting condition specified for LOOP in cond must select a contiguous block of rows of the internal table. Otherwise the behavior of the control level processing is undefined.

Well that's kind of reasonable. Here's a quick test program that you could run to see what's going wrong:

  data:
    begin of ROW,
      KEY1 type C,
      KEY2 type C,
      VAL  type I,
    end of ROW,
    ROW_TAB like standard table of ROW.

  ROW-KEY1 = '1'.
  ROW-KEY2 = '2'.
  ROW-VAL  = 1.
  append ROW to ROW_TAB.

  ROW-KEY1 = '2'.
  append ROW to ROW_TAB.

  ROW-KEY2 = '1'.
  append ROW to ROW_TAB.

  ROW-KEY1 = '1'.
  ROW-KEY2 = '2'.
  append ROW to ROW_TAB.

  ROW-KEY1 = '2'.
  append ROW to ROW_TAB.

  loop at ROW_TAB into ROW where KEY1 = '1'.
    write: / SY-TABIX, ':', ROW-KEY1, ROW-KEY2, ROW-VAL.
    at new KEY2.
      sum.
      write: / 'At New Key2 :', ROW-KEY1, ROW-KEY2, ROW-VAL.
    endat.
    at last.
      write: / 'At Last: sy-tabix =', SY-TABIX, 'sy-tfill =', SY-TFILL.
    endat.
  endloop.

Output is:

         1  : 1 2          1
At New Key2 : 1 2          1
         4  : 1 2          1
At New Key2 : 1 2          1

So as you can see, because I didn't select a contiguous block the AT NEW fired two times, even though it kind of looks as if nothing changed (i.e. for the lines present in the output key1 and key2 are identical). Also, note that the AT LAST event didn't fire, because we didn't reach the last line of the table.

So your coding looks ok, just be very careful when using conditions with AT events to avoid unexpected behavior. If you change my example though, you should see that all looks good when using a contiguous block (as in your example ensure through the sort order).

Cheers, harald