Так в других местах наш бедовый OLE-объект тоже не влияет на vbkey.

(Если быть точным, то LUW не меняется, т.к. счётчик update-модулей не сбрасывается. Меняется только vbkey.)


На вопрос не открывается ли обратная сессия, я ответил "нет".
А ещё раньше я писал, что обращение идёт к БД в локальной сети пользователя.

Любой прямой доступ к БД SAP — это извращение. А через обратную сессию — изысканное извращение. Когда я писал "не уверен на 100%, что это вообще всегда лишено смысла", то под обратной сессией имел в виду, например, RFC вызов, но только не обращение к БД SAP. Но в 99,99% любая обратная сессия, думаю, лишена смысла. Потому что у через вызов OLE метода можно передавать данные как туда, так и обратно.

А. Опять не так понял. Что за день такой
Я как раз таки подумал что OLE объект лезет в БД SAPы.

Вообщем мой вердикт: чертовщина какая-то

Если САП соизволит ответить (маловероятно, но все бывает) или докапаетесь до причины на месте - будет очень интересно узнать как так получается.
Т.к. по форуму, если не было аналогичной ситуации, слишком сложный для анализа вопрос.

Подведём итоги.

1. Использование wait until вместо do. loop. уменьшает вероятность глюков в родительском потоке на порядок (до 0,5%). Вероятность глюков в дочернем асинхронном процессе по прежденму велика и доходит до 45%.

2. Изменение ключа vbkey в таблицах vbmod, vbdata, а также в глобальной памяти %_vbkey и %%vbkey (для локальных обновлений) решает проблему: update модули стартуют и успешно выполняются.

3. Запрос отправлен в SAPnet. Если будет вразумительный ответ, отпишусь.