Добрый день,

проблема в следующем:

запускаю BAPI на создание объекта
а потом запускаю BAPI на изменение только что созданного объекта
и он не может его изменить пока не сделаю COMMIT после первой BAPI.

А мне нужно делать COMMIT после срабатывания 2ух BAPI.
Никто не знает, как мне это сделать?

Пока не сделаешь COMMIT WORK после первого BAPI объект в БД не создастся. И получается, что второй BAPI вроде как и не при делах
Вы поподробнее объясните, что хотите реализовать?

например,я создаю признак при помощи BAPI_CHARACT_CREATE. и потом хочу прикрепить к нему подробный текст при помощи BAPI_CHARACT_ADDLONGTEXT. а потом если не было ошибок сделать общий COMMIT. Как это сделать?

Насколько я в курсе, никак!

а смысл? чем не устраивает вариант с пормежуточным COMMIT ?

я привел лишь простой пример, на самом деле требуется гораздо более сложная конструкция (около 6 BAPI). где в случае ошибки необходим общий ОТКАТ!!!

А почему последовательно, то не получаится? Обратитсь к созданному объекту по ключу и добавить текст

Смысл очевиден и следует из свойств нормальных СУБД - целостность данных.

Короче вся суть проблемы сводится к тому, что если сделать insert в БД и не сделать COMMIT, то select этой добавленной записи не получится.

МОжет кто-то может мне объяснить реально ли полноценно несколько зависимых BAPI в один LUW запихнуть, или нет???

ГУРУ помогите!!!

Пару лет назад я пробовал, не получилось. Недавно товарищ пробовал, тоже не получилось.

Parazit, а кто тебе сказал, что R/3 - это нормальная СУБД?

В каждой BAPI перед вводом данных сначала идет считывание из БД и различные проверки, запись в БД идет после всех проверок и обработки данных.
Поэтому совместить несколько BAPI, которые обращаются к одним и тем же данным, нельзя.

только через промежуточный коммит. если очень хочется можно если 2я бапи не отработает запускать 3ю на удаление признака. но никто не гарантирует что отработает она=)

вообщем тут ничего криминального нет. раз 2 бапишки для признакв-текстов значит отдельно они вполне могут существовать

Вот, я и подчеркиваю различия между нормальной СУБД и R/3!

Видимо, планировалось, что TRANSACTION_BEGIN, TRANSACTION_END, BAPI_TRANSACTION_COMMIT и BAPI_TRANSACTION_ROLLBACK должны объединять несколько BAPI в один LUW. Но не уверен, что это во всех случаях работает. В принципе bapi создания и bapi изменения могут и не конфликтовать, посколько можно обойтись и без select'ов, а использовать глобальную область группы функций.