Столкнулся с вопросом, в котором абапер и базисник не знают, что и говорить....

Есть таблица ZEORD_CD. Есть цикл, который делает UPDATE по этой таблице. Этот цикл зависает на первом же UPDATE. Точнее, вылетает по таймауту.

Есть транзакция DB01. Там картинка такая:

ZEORD_CD HOLD 214 815248 872620 srvcrq 11202
ZEORD_CD __WAIT 231 942286 954580 srvcrq 2578

Первый процесс делает селект

SELECT "MANDANT" , "OBJECTCLAS" , "OBJECTID" , "CHANGENR" , "PAG
ENO" , "TIMESTMP" , "PAGELG" , "VARDATA" FROM "CDCLS" WHERE "MAN
DANT" = :A0 AND "OBJECTID" = :A1 ORDER BY "MANDANT" , "OBJECTCLA
S" , "OBJECTID" , "CHANGENR" , "PAGENO"

И держит второй. До того, как всё упадёт в таймаут.

Как с этим быть вообще?

Анализировать ABAP-код.
Потому что по таким исходным куцим сведениям можно много чего нагадать и не угадать.

В настройках таблицы ZEORD_CD- включен флаг "Запись в журнал изменений данных".
Если таблица большего объема, данный флаг будет тормозить процессы редактирования таблицы + см. Help

Таблица CDCLS - это кластер в нем лежат CDPOS, PCDPOS - это позиции документов изменений (а не журнала изменений)
но вот запрос к ней делается не по ключу как минимум в запросе не хватает where по полю OBJECTCLAS и не удивительно что он не выполняется таблица CDPOS как правило ооочень большая и ооочень быстро растёт.

Вряд ли такой косяк мог оставить САП скорее всего это какое то Z* творчество (кроме того и табличка на Z)

точно..попутал я
+ уж больно описание локов в тексте подходило под описание проблемы