Коллеги, я пытаюсь создать запись в BOPF БО, но у

меня создание не прокатывает, так как поначалу я несколько раз запустил modify с кривыми данными и теперь они где то висят и портят всю малину, такое впечатление что висят в буфере и при проверке повторно проверяются все записи.
Как то можно сбросить такие записи для работы с чистого листа?
Или я не на то грешу?

с вероятностью 99% не на то

Вот тогда фигня какая то. Я под своим логином пытаюсь создать записи и система ругается на отсутствие заполнения поля, которое в передаваемых данных заполнено, коллега те же записи прогоняет без ругани от системы

ставишь точку прерывания на мессагу, отладчик в руки и - алга

Ну алга то алга, modify не ругается, save ругается

можно проверить записи change_mode = /bobf/if_frw_c=>sc_modify_create

Мод установлен в create

те получить изменения lo_transaction->get_transactional_changes( ). и провреить есть ли ошибки в создоваемых записях lo_service->check_consistency( ) ?

В методах BOPF есть галочка что-то типа bypassing buffer(сейчас уже не помню в каких, дело было года 3 назад), попробуй её

Вот не нахожу пока, это не при создании экземпляра сервисманагера?

Не помню, у меня тогда была проблема со считыванием драфтов, вроде

В retrieve вроде было

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

Вот в момент проверки там туча записей которые невалидны и появляются когда система генерит изменения для объекта и видит кучу старых изменений которые не нужны

если удалить их вроде не проверяются

тогда проверяй последовательность действий над объектом. возможно, в какой-то момент записал изменения, которые делают объект невалидным. Никаких проблем со стороны фреймворка по обработке объекта не встречал. Всегда было дело в своих ошибках. Например: 2 обновления одной инстанции узла при вызове 1 модифай - это точно дамп. Ну и т.д.

есть ли транзакционных данных изменения ? DATA(lo_changes) = lo_transaction->get_transactional_changes( ). DATA(lt_changes) = lo_changes->get_changes( ).

это каждый раз надо удалять или как то хвосты почистить можно?

Не знаю точно, но судя что у вас есть “зависшые записи”, идет рассинхронизация GUI контрола с моделью данных. Рассинхрон может возникнуть от того что изменения были только в контроле (ALV или GUI tree) но не в модели BOPF (или наоборот). Golden rule после любой CUD операции Retrieve-ить данные. К примеру: программа создала или изменила запись и передала ее через REF #( ) ее в MODIFY. После этого обязательно нужно считать данные повторно, тк данные могут быть изменены в determination (время и автор изменения итп). MODIFY возвращает failed и success ключи по ним нужно сделать Read. Если программа проваливается в дочерние данные желательно неиспользовать “свои” кэши и обновлять контролы через повторное считывание через RETRIEVE_BY_ASSOCIATION или SELECT_BY_ELEMENTS