Да, всегда. Вообще не было ни одного случая COMMUNICATION_FAILURE или SYSTEM_FAILURE.

Родилась идея! Попробую заменить LOOP ... WAIT ... ENDLOOP на прогрессивную конструкцию WAIT UNTIL log_exp UP TO n SECONDS.

Это всмысле поиграться с освобождением-неосвобождением рабочих процессов?
Помнишь, еще обсуждали RZL_SLEEP ?

И еще, наверно не Ваш случай, но
http://www.sapnet.ru/viewtopic.php?t=436

Может, здесь что-нибудь найдётся...

а может просто на момент вызова аRFC просто нет свободных диалоговых процессов - поэтому ничего не выполняется и следов нет и несистемность ошибки.
И еще вопрос а вы используете aRFC чтобы откатить всю транзакцию - если в той части которая к GUI обращается какой-то сбой будет ?

Ещё раз повтрю, всё наоборот: основная программа, perform on commit и aRFC выполняются без ошибок (что достоверно фиксируется в БД SAP, в файлах на сервере приложений и в БД пользователя), update-модули — не стартуют.

Если возникает хотя бы подозрение на ошибку или таймаут, то усилием воли (message type X) всё валится в дамп без всяких колебаний.

так может VB процессов нет свободных на тот момент

может попробовать локальное обновление

И еще в документации нарыл:
Note that a database COMMIT may occur in certain circumstances after a WAIT statement. For this reason, do not use WAIT between two Open SQL statements that open and close a database cursor (such as SELECT...ENDSELECT).

COMMIT здесь роли играть не должен, т.к. даже если и происходит, то в другом LUWе.
Насчет попробовать LOCAL TASK - +1.

1.А почему другой LUW ?

All subroutines called with PERFORM ... ON COMMIT are processed in the LUW concluded by the COMMIT WORK command. All V1 update requests specified in CALL FUNCTION ... IN UPDATE TASK are also executed in one LUW. When all V1 update requests have been successfully concluded, the V2 update requests (update with start delayed ) are processed, each in one LUW. Parallel to this, the function modules specified in CALL FUNCTION ... IN BACKGROUND TASK are each executed in one LUW per destination.

2.здесь происходит COMMIT WORK в модуле PERFORM ON COMMIT

COMMIT WORK may not be used during the update (CALL FUNCTION ... IN UPDATE TASK) or during the execution of FORMs that were registered using PERFORM ... ON COMMIT or PERFORM ... ON ROLLBACK.

что происходит с модулями V1 IN UPDATE TASK - зарегистрированными для предыдущего LUW ? - они не выполняются

Если что-то не в порядке с процессом обновления, то всё отображается в sm13.


Если в perfrom on commit написать COMMIT WORK или ROLLBACK WORK, сразу будет дамп.

Да, Вы правы, не только WAIT, но и CALL FUNCTION ... STARTING NEW TASK, и create object вызывают DB commit. Не надо путать его с COMMIT WORK.

Что на самом деле происходит я уже написал: меняется vbkey.

Можно даже побаловаться и в perform on rollback вызывать CALL FUNCTION 'DB_COMMIT' и тогда все локальные обновления сохранятся, а update-процесс не стартует. Такой же эффект будет, если сначала вызвать DB_COMMIT, а потом ROLLBACK WORK. Но, насколько я помню, ROLLBACK WORK не меняет vbkey, а только очищает таблицы vbmod, vbdata. Меняет vbkey именно COMMIT WORK. В общем, всё это баловство и отношения к делу никакого не имеет.

************

Как известно, перед тем, как использовать помощь зала, не следует оглашать собственную версию. Так вот, открою последние карты: создание OLE объекта в среднем по ансамблю примерно в 20% случаев приводит к изменению vbkey вне зависимости от того, где он создаётся (в обычном процессе, в perform on commit или в асинхронном ф.м.). Когда это создание вынесено в асинхронный ф.м., то ОНО необъяснимым образом "просачивается" в родительский процесс и тоже вызывает смену vbkey, но происходит это существенно реже. К сожалению, проверить, что на самом деле происходит в ядре SAP непросто.

Более того, даже смоделировать ситуацию в лабораторных условиях не получилось. Создавал этот OLE объект в минимальной тестовой программе на своей персоналке ~100000 раз. ЭТО не случилось. Причин этому можно нафантазировать кучу: хотя бы то, что кол-во занимаемой оперативной памяти в тестовой программе минимально, а при создании документа материала в момент создания OLE объекта срывается стек и т.д. и т.п.

Что-то меня берут сомнения... какая связь может быть между созданием OLE - объекта и регистрацией процесса обновления?

IMHO, самое подозрительное звено, через которое могут взаимодействовать LUW основного и асинхронного процесса -это call-back функция. Может вообще отказаться от ее использования, и поскольку процессы запускаются на одном сервере приложений, в качестве флага завершения асинхронного процесса использовать SAP memory через GET/SET PARAMETER? Пусть даже в качестве эксперимента.
Все же есть подозрение на неудачное окончание работы через OLE.

Еще одна мысль, которую вроде здесь не поднимали, возможно глюк происходит на одном из серверов приложений, если их несколько в системе. Маловерятно, но...

PS: и еще, не ведется ли статистики, что глюк происходит в случае перекрытия процессов обновления от нескольких юзеров? Статистика ошибок наталкивает на эту мысль. Может блокировок каких-то добавить, чтобы недопускать перекрытие процессов, а выполнять их последовательно.

Вот, и меня тоже! Тем более, что одно на фронтенде, а второе — на сервере приложений. Однако статистика двух последних дней доказывает этот факт.

даёт vbkey1 <> vbkey2 в ~20% случаев!

Пошуршал по старым записям в табличках, когда ещё вызов OLE стоял до commit work, и понял, что именно это и случалось. Т.е. часть модулей обновления до OLE вызова регистрировались под одним ключом, вторая часть — под другим. Стартовала только вторая часть.

Сейчас вызов OLE стоит в самом конце, поэтому все модули обновления зарегистрированы под старым ключом и не стартует ничего.

************

Замена цикла ожидания на wait until, вроде бы, снизила вероятность возникновения таких случаев. Чтобы сказать уверенно, суточной статистики недостаточно, подождём несколько дней.
Состарюсь — книгу напишу: "Статистические методы анализа ошибок в программирвании".

Кажется я придумал простое решение проблемы "методом дяди Фёдора". Поскольу я знаю старый и новый vbkey, то в конце perform on commit можно подменить его в таблицах vbmod, vbdata!