Уважаемые коллеги!
Столкнулась с ситуацией:
в моей проге - запись в пользовательскую таблицу логов через insert (инфа по текущим результаттам работы программы). Между этими двумя записями - небольшая кучка операторов типа SORT, READ, loop - endloop. Ничего сложного, элементарнейшие действия, все линейно (то есть переходов в другие области проги между этими двумя "контрольными" строками нет)!
Но если я иду отладчиком от первой записи лога ко второй - все отрабатывает замечательно. Если даже просто - точку прерывания ставлю на второй записи - то все ok! Если же я пускаю "самотеком", то после первой записи вторая не появляется (и вместе с ней вылетает из выполнения еще кусок программы!). Данные, конечно, одни и те же...
SET UPDATE TASK LOCAL после первой записи не помог!
Что еще можно сделать в такой ситуации? НЕ ставить же запись в логи после каждого оператора...
Пожалуйста, подскажите!

Наташа,
COMMIT WORK AND WAIT
после INSERT не спасет отца русской демократии?

к сожалению, результат тот же...

я его вообще убрала - поставила COMMIT WORK AND WAIT, как Вы сказали..... После первой записи, и после второй то же (ну, на всякий пожарный)...
но нифигаськи...

SET UPDATE TASK LOCAL страбатывает, если <я не знать русский языка> ни одного INSERT (UPDATE, DELETE). То есть проверьте, что выше нет опереторов обновления базы.


SET UPDATE TASK LOCAL.
INSERT ...
COMMIT WORK AND WAIT.

Коллеги, SET UPDATE TASK LOCAL тут вообще ни при чем - он действует в рамках одного LUW и управляет тем, как будут выполняться фукнции, вызванные вот так: CALL FUNCTION ... IN UPDATE TASK, к простым INSERTам это никак не относится...
Может программку в студию?

вот оно... только прошу не кидать несвежими овощами - функциональщик я...
Вся прога очень длинная, привожу только кусок с прилагающимися DATA xmkpf TYPE mkpf.
PERFORM <запись в пользовательскую таблицу, таблицу, insert >
COMMIT WORK AND WAIT.
• цель нижеследующего – отобрать самую последнюю запись (по времени выполнения)
• по нужной дате

SORT xmkpf BY cpudt DESCENDING.
READ TABLE xmkpf INDEX 1.
xdat = xmkpf-cpudt.
LOOP AT xmkpf.
IF xmkpf-cpudt NE xdat.
DELETE xmkpf.
CLEAR xmkpf.
ENDIF.
ENDLOOP.
CLEAR wa_mkpf.
READ TABLE xmkpf INDEX 1 INTO wa_mkpf.
xsysubrc = sy-subrc.
PERFORM <вторая запись в пользовательскую таблицу, таблицу, insert >
COMMIT WORK AND WAIT.

Так а внутри PERFORMа что?

Вот такое:
FORM add_log_data USING value(type) value(id) value(no) "TYPE symsgno
value(v1) value(v2) value(v3) value(v4) .
DATA: msg TYPE bal_s_msg.
TABLES zsdmess_st.

msg-msgty = zsdmess_st-msgty = type.
msg-msgid = zsdmess_st-msgid = id.
msg-msgno = zsdmess_st-msgno = no.
msg-msgv1 = zsdmess_st-msgv1 = v1.
msg-msgv2 = zsdmess_st-msgv2 = v2.
msg-msgv3 = zsdmess_st-msgv3 = v3.
msg-msgv4 = zsdmess_st-msgv4 = v4.

msg-msgty = zsdmess_st-msgty = type.
msg-msgid = zsdmess_st-msgid = id.
msg-msgno = zsdmess_st-msgno = no.
msg-msgv1 = zsdmess_st-msgv1 = v1.
msg-msgv2 = zsdmess_st-msgv2 = v2.
msg-msgv3 = zsdmess_st-msgv3 = v3.
msg-msgv4 = zsdmess_st-msgv4 = v4.

zsdmess_st-sydatum = sy-datum.
zsdmess_st-syuzeit = sy-uzeit.
zsdmess_st-uname = sy-uname.

SELECT SINGLE text FROM t100 INTO zsdmess_st-text
WHERE sprsl = 'R' AND arbgb = zsdmess_st-msgid AND msgnr = zsdmess_st-msgno.
INSERT zsdmess_st.
ENDFORM. " add_log_data

Таблица Z* мандантозависимая?

Похоже дело в дублировании ключа.
zsdmess_st-sydatum = sy-datum.
zsdmess_st-syuzeit = sy-uzeit.

При выполнении без отладки время в ключе одинаковое, поэтому новая запись и не вставляется.

Добавьте к ключу еще поле счетчика и приращайте на 1.
Или вставьте задержку на 1 сек. между Insert

эээ... ну, содержимое - нет, а сама она - во всех мандантах одной системы... то есть - как обычно!

упс! а задержка - это какой оператор?
Просто Do <офигеть сколько> times?

WAIT UP TO 1 SECONDS.

Наташа, если INSERT много, подумайте насчет введения нового поля ID. Зачем Вам терять N сек на выполнении.