Редактируемый ALV-Grid: как построить дельта-таблицы для сохранения изменений?

Chaser009

Здравствуйте!

Возникла задача реализовать функционал для редактирования данных в ALV Grid c последующим сохранением в таблицу БД.
Опыта в АБАП мало, поэтому для примера взял отчет BCALV_EDIT_04, но там сразу наткнулся на ошибки в логике работы.

Никто не пытался реализовать что-то похожее именно с использованием дельта-таблиц для хранения истории изменения данных? Или может, где примеры внятные посмотреть можно?

Удав

Зачем для этого дельта-таблицы?
Достаточно поля "индикатор изменений" и одной таблицы для удаленных записей.

Chaser009

Ну в принципе я уже тоже пошел по такому варианту. Еще раз повторюсь: опыта работы с редактируемым ALV нет, поэтому пока начал понимать логику его работы, три раза код переписал :-)

nicky555

коллеги, все придумано до нас

1) делаем структуру YZTAB, состоящую из include ZTAB (ваша таблица) и include ICDIND (индикатор изменения).
2) объявляем две внутренних таблицы LT_ZTAB_NEW & LT_ZTAB_OLD структуры YZTAB. Первую заполняем свежими данными перед сохранением, вторую - старыми данными в начале работы программы.
3) вызываем что-нибудь а-ля

Code:

  DATA: ld_result TYPE c.

  CALL METHOD cf_reca_storable=>get_change_indicator
    EXPORTING
      tablename              = 'ZTAB'
    IMPORTING
      RESULT                 = ld_result
    CHANGING
      table_new              = lt_ztab_new
      table_old              = lt_ztab_old
    EXCEPTIONS
      nametab_error          = 1
      wrong_structure_length = 2
      OTHERS                 = 3.
  IF sy-subrc <> 0.
*   Обработка ошибок
  ENDIF.

  IF ld_result <> 'F'.
*   Данные не изменены, обновлять ничего не нужно
  ENDIF.

Вот и все - в таблице LT_ZTAB_NEW имеем только измененные записи с заполненным индикатором KZ = {I,U,D}. Отдаем ее в свой ФМ обновления и радуемся жизни

P.S.: Для тех, у кого в системе нет заветного класса CF_RECA_STORABLE, жизнь немного усложнится - надо отсортировать таблицы по ключу и сравнить записи, расставив признак изменения. Можно также использовать для этого ФМ CHANGEDOCUMENT_PREPARE_TABLES.

Chaser009

Так как в отчете необходимо редактировать несколько таблиц, и все они имеют разную структуру, я нарисовал класс-потомок ALV Grid'а, внутри которого уже реализуются все необходимые шаги по проверке данных при вводе, отслеживанию изменений и сохранению данных в соответствующие таблицы БД. Внутренние структуры и таблицы в классе практически все создаются динамически, поэтому, мне проще делать по пути, предложенному уважаемым Удавом.
В моем случае мне кажется, что перелопачивать две таблицы, чтобы найти 2-3 измененные записи, как-то нерационально. Хотя, вполне возможно, я ошибаюсь, так как сам занимаюсь PI, и в ABAP не силен (базовые знания). Вот поэтому и прошу совета у гуру :-)

.

Helper

Если в редактируемом АЛВ очень большая таблица(миллионы + много полей) и редактируются 2-5 полей, то некорректно создавать ещё и дельта-таблицу.
Память сессионная закончится раньше. В этом случае добавляю 2-5 технических полей со скопированными старыми значениями.
А при сохранении тупо анализирую совпадают вновь введённые значения или нет со старыми.

RA

Цитата:

Если в редактируемом АЛВ очень большая таблица(миллионы + много полей) и редактируются 2-5 полей, то некорректно создавать ещё и дельта-таблицу.

В этом случае некорректно создавать редактируемый АЛВ

Правила форума

Редактируемый ALV-Grid: как построить дельта-таблицы для сохранения изменений?

Кто сейчас на конференции