Есть программа, которая меняет признаки. Работает просто - для каждого ЕО вызывается BAPI_OBJCL_CHANGE. Если ошибок нет, то

Попросили добавить добавить вывод значения признака ДО внесения изменений и ПОСЛЕ. Проблема в том, что без параметра WAIT нет ожидания, когда данные внесутся в таблицы. Поэтому иногда при чтении новых значений читается старое значение, так как новое не успевает лечь в таблицу.
Прикрутил эвристику в виде "если успешно изменилось, а значения не равны, то давайте попробуем подождать 10 секунд и опять считать значения". Но какое-то кривое решение, на мой взгляд. К тому же не дающее 100% гарантии верности значений.

Может, есть более прямые решения, которые я не вижу?

p.s. Само собой, добавление параметра WAIT = 'X' поможет, но тогда скорость уменьшится.

А если попробовать ставить WAIT после последнего вызова BAPI?
Один COMMIT после вызова всех BAPI, как я понимаю, не получится сделать (записей много?), также как и брать значения из параметров с которыми запускаются BAPI в качестве выводимых в отчет значений "ПОСЛЕ" (могут отработать экзиты и процедуры в классификации?).

Честно говоря не пробовал потмоу что как-то сомнительно что дополнительный вызов
Будет ждать все предыдыщие вызовы.
Получается что если вызвать "COMMIT WORK AND WAIT." то он будет ожидать все предыдыушие "COMMIT WORK."?

вот код 'BAPI_TRANSACTION_COMMIT'



т.е этот фм делает коммит и чистит буффер и все.

Код ФМ-а я смотрел. Т.е. если сделать 10 раз "COMMIT WORK.", а потом один раз "COMMIT WORK AND WAIT.", то этот последний коммит будет ждать пока все 11 коммитов не внесут данные в таблицу?

Посмотрите в сторону SET UPDATE TASK LOCAL ...

Если скорость важна и признаки меняет Ваша программа, то почему тогда нельзя новые значения признаков брать сразу из параметров BAPI_OBJCL_CHANGE?

Потому что то, что подается в BAPI, и что в итоге пишется в БД, в общем случае не одно и то же.

А ждать 10 сек или селектиться в цикле это лучше?
Почитайте что такое синхронное и асинхронное обновление и сразу станет понятно.
В чем проблема в wait? что у Вас там за объемы такие?
Ну и как посоветовал nicky про локальное обновление (это синхрон тоже)

По существу задачи, зачем городить это, ДО/ПОСЛЕ, если стандартные механизмы - журнал изменений (change docs), там все видно, кто изменил, когда, какое старое значение, какое новое...

1. Модули обновления используют блокировки. Поэтому перед чтением смотрите, есть ли блокировки на классификацию
2. Скорость уменьшится, если использовать шаг 10 с.
3. Прислушайтесь к Besa по поводу журнала изменений. И кстати, старое значение вам известно, новое тоже. Если ФМ BAPI_OBJCL_CHANGE отработал успешно, зачем ждать, когда изменения отразятся в БД?

В данном случае это как раз одно и то же. "Зависшими" обновлениями занимаются базисники

Может в конкретном случае и так, мы не знаем. Но в общем случае нет.
Речь не про зависшие обновления, а про то, что внутри BAPI могут производиться "махинации" с входными данными (userexit и прочий Z). И на выходе (в БД) может быть вообще всё что угодно. Я только в этом случае вижу необходимость проверять значения ДО/ПОСЛЕ.