Binary search not working when looping on the same table - abap

Question

I'm making a function that exports a table with some data T_DATA[].
There is a part when I loop through an internal table( T_ENTRIES[]) and use binary search on the T_DATA[].
Before the Loop, T_DATA[] is sorted by the key I use in the read statement.
For some reason, the read fails a lot of time even if it has same key in both tables.
If i remove the binary search it works well.
Is this a common problem with tables that declared as exporting in the function?
Because when I move the table (T_DATA[]) to a different internal table and use the binary search on it, it works fine.
Thank you!
SORT t_patient_list[] BY kunnr.
LOOP AT lt_cov_entry[] ASSIGNING FIELD-SYMBOL(<ls_cov_entry>).
READ TABLE t_patient_list[]
ASSIGNING FIELD-SYMBOL(<fs_patient_list>)
WITH KEY kunnr = <ls_cov_entry>-kunnr.
BINARY SEARCH.
IF sy-subrc <> 0.
CLEAR ls_patient_record.
MOVE-CORRESPONDING <ls_cov_entry> TO ls_patient_record.
APPEND ls_patient_record TO t_patient_list[].
ELSE.
<fs_patient_list>-hosp_type = <ls_cov_entry>-hosp_type.
ENDIF.
ENDLOOP.

Answer 1

It does not work with BINARY SEARCH becuse the APPEND ruins the ordering. The best solution is to define t_patient_list as SORTED by kunnr. 1
If you cannot do that, you should use INSERT ... INDEX sy-tabix instead of APPEND, as even a failed READ TABLE sets it to the right value:
SORT t_patient_list[] BY kunnr.
LOOP AT lt_cov_entry[] ASSIGNING FIELD-SYMBOL(<ls_cov_entry>).
READ TABLE t_patient_list[]
ASSIGNING FIELD-SYMBOL(<fs_patient_list>)
WITH KEY kunnr = <ls_cov_entry>-kunnr
BINARY SEARCH.
IF sy-subrc <> 0.
CLEAR ls_patient_record.
MOVE-CORRESPONDING <ls_cov_entry> TO ls_patient_record.
INSERT ls_patient_record INTO t_patient_list[] INDEX sy-tabix.
ELSE.
<fs_patient_list>-hosp_type = <ls_cov_entry>-hosp_type.
ENDIF.
ENDLOOP.
1 ) If you can change it to SORTED, you still need to replace APPEND with INSERT, just without the INDEX part.

Answer 2

The problem is that you are appending to the table while you are reading it. After you append something, it might no longer be sorted, so BINARY SEARCH can no longer be expected to work reliably.
Possible workaround:
When the definition of the table t_patient_list is under your control, then add a secondary sorted table key to its declaration:
DATA t_patient_list TYPE TABLE OF patients
WITH NON-UNIQUE SORTED KEY key_kunnr COMPONENTS kunnr.
(you might use an even faster UNIQUE HASHED KEY when you can guarantee that kunnr includes only unique values)
Then explicitly use that key when searching:
READ TABLE t_patient_list[]
ASSIGNING FIELD-SYMBOL(<fs_patient_list>)
WITH TABLE KEY key_kunnr COMPONENTS kunnr = <ls_cov_entry>-kunnr.
(The addition BINARY SEARCH isn't required here because using a sorted key implies binary search).
Secondary keys are updated whenever the table is changed, so you can rely on them staying consistent.
More hackish workaround
When the definition of the table t_patient_list is not under your control, then you have to re-sort the table after changing it:
IF sy-subrc <> 0.
CLEAR ls_patient_record.
MOVE-CORRESPONDING <ls_cov_entry> TO ls_patient_record.
APPEND ls_patient_record TO t_patient_list[].
SORT t_patient_list[].
ELSE.
But you might want to measure if the performance penalty of sorting it after every append isn't more than you save by using BINARY SEARCH.