В BSP-скрипте вызываю функцию в UPDATE TASK.
Функция вставляет данные в таблицы и работает с функциями BPS.

В диалоговом режиме все работает корректно.
В UPDATE TASK работает около 2-х минут, потом завершает работу, результатов которой не видно


Что может быть?
(если нужны уточнения - сообщу)
Может такая функция ничего не должна возвращать (в описании EXPORTING нет, есть только TABLES)?
Или наоборот что-то должна возвращать?
В свойствах выставлено:
Модуль обновления -> Немедленный запуск

Спасибо!

она изменяет таблицы БД?

Да...

COMMIT WORK.
не забыли???

Хороший вопрос!
В вызывающем есть
и в вызываемом есть
Я тут еще погонял функцию, выпадает в дамп на ROLLBACK WORK.

А почему???

ROLLBACK is not allowed during an update (CALL FUNCTION ... IN UPDATE TASK)

хм... а как бы и рыбку и ...
т.е. асинхронно вызвать функцию и чтоб коммит или ролбэк в ней отработал корректно.

Из кода функции обновления уберите COMMIT WORK - этого нельзя. COMMIT должен быть только в вызывающей функции.

О как! Надо будет запомнить. А причину такого запрета в двух словах не опишите?????

2 G: Нужно просто правильно продумать процедуру сохранения. Тогда возможно отпадет вариант с не совсем верными желаниями

2 Loyso: А это просто принцип сохранения такой. Модули, которые вызываются в UPDATE TASK начинают свою работу, в тот момент, когда в вызывающей программе отрабатывает COMMIT WORK. Т.е. вызываете последовательно несколько таких модулей, потом один раз говорите коммит и все обновления массой сливаются в базу. Подробнее - курс BC 414 + help на слова LUW и "обработка транзакций"

Дело в том, что COMMIT WORK есть в том числе и явный вызов database commit. А если внутри одного из модулей обновления в процессе самого обновления отработает database commit, то тогда может произойти ситуация, когда часть обновлений пройдёт, а часть - нет. А именно для того, чтобы избежать этой ситуации и был придуман механизм модулей обновления. Поэтому внутри модулей обновления запрещены все операторы, которые могут спровоцировать - явно или неявно - database commit или database rollback.

Спасибо за инфо

Вполне понятно почему нельзя делать коммит в UPDATE TASK
(мне нужен был асинхронный режим выполнения ФМ потому я перешел на использование BACKGROUND TASK там коммит -- не преступление).

Можно поподробнее вот об этом:
?
Для того чтобы прошли все обновления или ни одного был придуман механизм транзакций. А вот для чего механизм UPDATE TASK мне не очень понятно.
Предполагаю, чтобы асинхронно выполнить длительные вычисления в рамках текущей транзакции (тогда чем отличается от BACKGROUND TASK?).

Дело в том, что когда в программе выполняется последовательность модулей обновления Вы вольны делать database commit когда угодно - на обновление БД это не повлияет. Полная последовательность этих модулей будет выполнена (или не выполнена) в процессе обновления, который буде запущен после COMMIT WORK. Когда же выполняется непосредственно обновление внутри процесса обновления операторы, инициирующие database commit/rollback внутри модулей обновления делят весь процесс на части.

Если интересно, посмотрите по-подробнее о понятиях Database LUW и SAP LUW.

1) Можно вызвать обновления БД непосредственно в программе, тогда в случае сбоя, все обрабатывать надо самому + т.к. СУБД по традиции это узкое место : занимаются ресурсы, что есть нехорошо.
2) Обновления в UPDATE TASK или гарантировано все доедут или гарантированно все не доедут в рамках 1-ого LUW. В случае, если они не доехали, есть возможность через sm13 посмотреть и как-то исправить ситуацию. Так же, т.к. это работает через предопределенные разработчикми Р3-механизмы, достигается экономия ресурсов. Самое главное: это не асинхронный вызов, т.е. по идее программа дождается подтверждения сохранения.(Как пример: можно воткнуть точку остановки в проводке, когда она будет достигнута - остановить обновления в системе, и продолжить проводку. Все повиснет )
3) BACKGROUND TASK - асинхронный вызов + транзакционный вызов в RFC