DELETE ADJACENT DUPLICATES delete order?

Question

If there are entries with the same key.

sort itab by key. delete adjacent duplicates from itab comparing key.

Does anyone know which one will be deleted if delete adjacent duplicates..comparing key? The first one or second one?

Tiedeman

SE38 and the debugger would help with a fun test in answering this question in a practical manner :) – Disgust

Remember to sort STABLE, if you want to use this feature. – Breannabreanne

Answer 1

From F1 help on "delete adjacent duplicate"

In the case of several double lines following one another, all the lines - except for the first - are deleted.

So the second (identical) line should be deleted

Regards,

Illuminant

Answer 2

Instead of sorting a standard table, you could consider declaring another internal table as a sorted table of the same type with a unique key corresponding to the fields you're comparing to eliminate the duplicates. It's faster, allows you to keep your original table unchanged, and, in my opinion, makes your code more readable because it's easier to understand which rows are kept and which ones are not. Example:

LOOP AT itab ASSIGNING <itab_row>.
  INSERT <itab_row> INTO TABLE sorted_itab.
ENDLOOP.

Constriction

Actually, it's not faster when you have a high number of writes, compared to the number of reads. The fact that you are copying the table line for line (before sorting), means that the program has to calculate the correct index of each row separately. Also, if you defined sorted_tab with a unique key, you will get a runtime error once you reach the second row with the same key. If you defined sorted_itab with a non-unique key, you just end up with a sorted copy of your unsorted table. – Kaleykaleyard

Did you actually verify this before downvoting my answer? Because both your claims are incorrect. The INSERT statement will not cause a runtime error when it encounters a duplicate primary key; it will simply return subrc 4 and continue without inserting the row. I've also done some testing of both implementations, and it appears my solution is exponentially faster than sorting and deleting adjacent duplicates (if you want I can provide you with a test program and the results). – Cyndy

My apologies it was an unwarranted downvote, and I actually thought I cancelled it after submitting my comment on the 19th. You are correct regarding the runtime error. There is a higher overhead to SORTED tables when you have a high number of writes to the table, but I did not account for the saving in performance that you would have by bypassing the "delete adjacent duplicates" statement. If you can make a minor edit to your answer, I will cancel the downvote. (I'm not allowed to cancel it as-is, as the vote happened to far in the past). – Kaleykaleyard

Cheers Esti. I wish I could edit a comment as well, because after some more testing I noticed it's not exponentially faster, just linearly, but still faster. – Cyndy

Answer 3

If data in your itab are fetched from DB, it's better than you use ORDER BY addition in SELECT and than you can use the delete adjacent duplicates . Sorting algorithm costs nlog(n) and is better that DBMS does these type of operation instead ABAP. Obviously that if you can do the DISTINCT or GROUP BY in SQL you avoid to use both SORT and delete adjacent duplicates and you should solve all performance problems

Viscoid