Всем привет.

Задачка состоит в том, чтобы обновлять данные по изменениям ALV таблицы. Обновлять скопом, чтобы базу меньше дергать. Для этого сделал буфер, с которым сравниваю ALV и при сохранении, сохраняю все сразу. Все было прекрасно пока табличка была одна, сейчас добавился еще экранчик, в котором могут менятся данные отображаемые на 1 экране. В базе эти изменения прописываются на экране 2. Т.е. мне при изменении данных приходится обновлять и буфер и ALV1. Следить за 2мя таблицами лень и функцию обновления не хочется всегда запускать(да и при доработках, другой разработчик может на нее забить). Хочу обновлять буфер из ALV1 при переходе на экран с другого экрана. Можно ли узнать в PBO логике, что произошла смена экранов?

Посмотрите ноту 415716, раздел "General information about the internal tables of delivery processing" для получения информации, как нужно организовывать буфер для хранения табличных данных.

А какой смысл изобретать велосипед? Используйте ФМ обновлений IN UPDATE TASK. Тогда функция сохранения будет состоять из одной команды COMMIT WORK, вместо сравнений различных как правило глобальных внутренних таблиц.

Подумал что быстрее будет + скучновато было В итоге через обновления буду делать.

Для редактируемых ALV хорошо накладывается сохранение in update task. Но бывают исключения - когда постановщики хотят сделать возможность сохранять не все что сделано, а к примеру только выделенные записи.

А что, неявных COMMIT не бывает?

Пардон, причем тут неявный commit? Может я выразился неправильно - на мой взгляд механизм отложенных обновлений очень удобно использовать, когда сохраняются все изменения, выполненные пользователем. А вот если не удается уговорить сохранять целиком(например требование сохранять не все строки, в которых были изменения, а только выделенные) - тогда пользоваться отложенными обновлениями неудобно, приходится анализировать изменения по внутренним таблицам.

Насколько я понял из контекста, вы предлагаете при каждом изменении выполнять ФМ в режиме IN UPDATE TASK и по кнопке "Сохранить" вызывать COMMIT WORK?
Если так, то изменения будут выполняться не только при нажатии кнопки сохранить, то и при любом срабатывании логики экрана.

Не будут. нужен явный комит.

Именно так. Отложенные обновления не инициируются неявным коммитом, как раз для этого они и нужны. Рекомендую ознакомиться с курсом BC414.

Мда, насчет неявного COMMIT и режимом IN UPDATE TASK я вступил