Артем, может, я не правильно выразился...
суть такова: вызываем ба пи, внутри - вызов модуля обновления.. пишу commit work and wait. теоретически система освобождает диалоговый процесс, ждет, пока не отработают все модули обновления, т.е все операторы кода, идущие после commit work, не должны выполниться , пока не отработают все модули обновления. т.е. если мы грузим данные в систему, то после commit селт должен возвратить что-то, а не четверку. процесс получается как бы синхронный. это в теории.

Art386, вот в теории и есть заковыка. Для V1 все верно написано. Для V2 - нет. Т.к. все V2 модули обновления выполняются асинхронно вне зависимости от того, написали вы wait или нет.

З.Ы.: Прошу прощения за сарказм в предыдущем посте. Не смог удержаться

я в курсе, как работают модули V2
записи запросов обновления для V2 всегда хранятся в VBLOG, т.е. не зависят, есть ли SET UPDATE TASK LOCAL или нет.
в описанном же мною случае SET UPDATE TASK LOCAL помог, значит в данном случае V2 не использовались...

З.Ы.
а SQL-trace отражает запросы именно в том порядке, как они шли. т.е. можно отследить реальную последовательность выполнения.
т.е. если написать COMMIT WORK AN WAIT, а затем SELECT, или COMMIT WORK, а затем SELECT, то в трейсе это будет выглядеть совершенно по-разному

Чтобы делать выводы, тут нужно наверняка знать. Хотя бы из той же самой ST05 можно провалиться в код ф.м. обновления и посмотреть, что это за зверь. Потому что если два процесса работают асинхронно, то, в зависимости от обстоятельств, первым может закончиться любой, в том числе и V2, особенно если он запустился на другом, незагруженном, сервере приложений.

Ещё нужно проверить, не буферизована ли таблица на сервере приложений.

И только после всего этого можно утверждать, что БД не успела закоммитить или что-то буферизовала.

Согласен, надо конкретно найти ту бапи и посмотреть, что внутри...



но ведь никакой V2 не может закончиться раньше какго-нибудь V1? ведь все V2 запускаются только после успешной отработки всех V1.

Так select-то у вас возвращал 4 в диалоговом процессе после commit work and wait, а не в V1.

Art386, на все есть своя причина.

Чтобы предметно говорить - хорошо бы увидеть код.

Т.к.:
1. Я вполне допускаю, что внутри БАПИ использовались ФМы обновления V2 (равно как и V1, их вполне может быть больше одного).
2. Мне не совсем ясно, что означет "SET UPDATE TASK LOCAL помог". Запись в таблице стала находиться select'ом?
3. Не известно, был ли какой-либо код между вызовом BAPI и COMMIT WORK AND WAIT. Т.к. он мог повлечь неявный коммит.
4. sibrin вполне верно заметил про буферизацию.

З.Ы.: Я не говорил, что ST05 криво работает. Я предпологаю, что вы неверно интерпритировали результаты