Двоичный поиск не работает при зацикливании на той же таблице - PullRequest
Новая
       147

Двоичный поиск не работает при зацикливании на той же таблице

0 голосов
/ 03 августа 2020

Я делаю функцию, которая экспортирует таблицу с некоторыми данными T_DATA []. Есть часть, когда я l oop через внутреннюю таблицу (T_ENTRIES []) и использую двоичный поиск по T_DATA []. Перед L oop T_DATA [] сортируется по ключу, который я использую в операторе чтения. По какой-то причине чтение часто терпит неудачу, даже если он имеет одинаковый ключ в обеих таблицах.

Если я удалю двоичный поиск, он работает нормально.

Это обычная проблема с таблицами который объявлен как экспорт в функции?

Потому что, когда я перемещаю таблицу (T_DATA []) в другую внутреннюю таблицу и использую в ней двоичный поиск, она работает нормально.

Спасибо ! 

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.

1 Ответ

1 голос
/ 05 августа 2020

Проблема в том, что вы добавляете к таблице, пока читаете ее. После того, как вы что-то добавляете, это может больше не сортироваться, поэтому нельзя ожидать, что BINARY SEARCH будет работать надежно.

Возможный обходной путь:

Когда определение таблица t_patient_list находится под вашим контролем, затем добавьте в ее объявление ключ вторичной отсортированной таблицы: 

DATA t_patient_list TYPE TABLE OF patients 
                         WITH NON-UNIQUE SORTED KEY key_kunnr COMPONENTS kunnr.

(вы можете использовать еще более быстрый UNIQUE HASHED KEY, если вы можете гарантировать, что kunnr включает только уникальные значения)

Затем явно используйте этот ключ при поиске: 

READ TABLE t_patient_list[]
    ASSIGNING FIELD-SYMBOL(<fs_patient_list>)
    WITH TABLE KEY key_kunnr COMPONENTS kunnr = <ls_cov_entry>-kunnr.

(добавление BINARY SEARCH здесь не требуется, поскольку использование отсортированного ключа подразумевает двоичный поиск).

Вторичные ключи обновляются каждый раз при изменении таблицы, поэтому вы можете рассчитывать на то, что они останутся согласованными.

Больше хаки sh обходной путь

Когда определение таблица t_patient_list находится под вашим контролем не , тогда вам нужно пересортировать таблицу после ее изменения: 

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.

Но вы можете захотеть измерить, если снижение производительности сортировка после каждого добавления не больше, чем вы сэкономите, используя BINARY SEARCH.

...