Is it safe to have nested loops on the same internal table?

[Former Member]

Hello experts,

I am wondering that whether the follow code is legal/safe:

CLEAR old_key.

LOOP AT itab INTO itab_wa.

  IF itab_wa-key <> old_key.

    old_key = itab_wa-key.

    LOOP AT itab INTO itab_wa1 WHERE key = old_key.

*       do some processing here.

    ENDLOOP.

  ENDIF.

ENDLOOP.

Thanks and best regards.

zj

[Former Member]

If the code is unclear then the maintenance of the code will be expensive, and lead to errors.

Try:

SORT ITAB BY key.

CLEAR old_key

LOOP AT itab INTO itab_wa.

  IF itab_wa-key <> old_key.

    old_key = itab_wa-key.

*   Do first time through processing.

  ENDIF.

• Do some processing here.

ENDLOOP.

If you do not have any need for first time through process then you do not need 'old_key'.

[TMNielsen]

Hello Matthew / zj

If you modify the example a little, Matthew's rewritten code would not give the same proccesing as zj's code. I think zj try to do some LAST time processing and Matthew try to do some FIRST time processing?

CLEAR old_key.

LOOP AT itab INTO itab_wa.

  IF itab_wa-key <> old_key.

    old_key = itab_wa-key.

    LOOP AT itab INTO itab_wa1 WHERE key = old_key.

*       do some processing here when a new key occurs

    ENDLOOP.

  ENDIF.

*    do some processing here for all records <-- this is the modification of example

ENDLOOP.

I'm sure the code is safe, but you must be carefull if you'r using sy-tabix.

On the other hand I see no reason for building the code in this way.

I can't imagine where I would need this processing, but if - I think I would use 2 tables and the AT NEW and/or AT END OF statements.

Best regards

Thomas Madsen Nielsen

[Former Member]

Thomas / ZJ

The difference between first and last time processing, is where you update the old_key. Thus:

CLEAR old_key.

LOOP AT itab INTO itab_wa.

  IF itab_wa-key <> old_key.

    LOOP AT itab INTO itab_wa1 WHERE key = old_key.

*       do LAST TIME processing here when a new key occurs

    ENDLOOP.

    old_key = itab_wa-key.

    LOOP AT itab INTO itab_wa1 WHERE key = old_key.

*       do FIRST TIME processing here when a new key occurs

    ENDLOOP.

  ENDIF.

*    do some processing here for ALL records <-- this is the modification of example

ENDLOOP.

I agree with Thomas that if the table cannot be processed in one pass (as my example) the solution is to process it in two passes or to use two tables.

My fundemental objection to this logic is, I could not guarantee that this code would allways give the correct result.

Other that that, A) the code is not clear in its meaning. What is happening to sy-tabix, sy-index? If the program had an abnormal end could you debug it, to say which record(s) it failed on? Inner and outer loops!

B) Processes the the table twice when once should be enough, (performance). How many times are you reading each row?

C) What happens if the table is not in order. For example; key_A, key_C, then key_A again, gives a different result to key_A, key_A, key_C.

All the best

Matthew Gifford.

[Former Member]

Me too, I think the code is okay. It could be better as Matthew mentioned.

But there is one good advice when using the variable sy-tabix:

save it as soon as possible!

Code:

CLEAR old_key.

LOOP AT itab INTO itab_wa.

  outer_sy_tabix = sy-tabix. " save sy-tabix

  IF itab_wa-key <> old_key.

    old_key = itab_wa-key.

    LOOP AT itab INTO itab_wa1 WHERE key = old_key.

*       do some processing here.

    ENDLOOP.

  ENDIF.

• process outer sy-tabix

  if outer_sy_tabix = 1.

    ....

  endif.

ENDLOOP.

If you're doing things in a LOOP, for example another loop or a perform or other things, and you have to use sy-tabix in the lower part of the loop, always save it!

The same is to do with other system variables as sy-index or sy-subrc in similar cases.

KInd Regards Axel Kiltz