Delete the current row from an internal table in a loop
Can I safely delete the active row while looping over an internal table?
As an example, consider this code:
LOOP AT lt_itab INTO ls_wa.
IF [...] . " A check that can't be done inside a 'DELETE lt_itab WHERE'
DELETE lt_itab INDEX sy-tabix
" OR
DELETE lt_itab FROM ls_wa.
ENDIF.
ENDLOOP.
Is it safe to delete records like this or will this logic not behave as intended?
Should I instead store the unique identifier for the rows in a temporary itab and run a DELETE lt_itab WHERE after the loop?
I assume that delete operations on records other than the one that is loaded in the current iteration will definitely cause issues but I'm unsure if this is a valid, let alone good practice.
Answer
Whether it is safe or not depends largely on your coding skills. It has a defined result, and it's up to you to use the commands correctly. It is usually safe if nothing else happens after the DELETE statement within the loop. You can issue a CONTINUE statement right after the deletion to make sure that this is the case.
Do not use DELETE lt_itab INDEX sy-tabix. If you use some statement within your check that changes sy-tabix as a side effect (for example, looking up some entry in a check table - or calling a function module/method that does so), you will end up deleting the wrong lines.
Be aware that you can simply use the statement DELETE lt_itab. in your example since the line to delete is the current one.
If your table can have multiple identical lines, your second variant DELETE lt_itab FROM ls_wa. will delete all of them, not just the current one - whether that is intended depends on your requirements.
EDIT: To reiterate the "defined result": The current line is deleted. There is no "continuing with the next line" - with the addition INTO var you actually copied the entire line into your variable. That variable won't be touched, it's just out of sync with the table. This might be intentional - the system has no way of knowing this. If you use a field symbol instead, it will be UNASSIGNED, which - again - might be what you intended - and then again maybe not.