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

не факт.

Мы не видели кода этой программы,
а в RCU_UPLOAD_EXCEL_TO_VTAB как раз пример правильной работы с таблицами вариантов.

если предварительно не удалить содержимое таблицы
или грузить частями,
то CAMA_TABLE_MAINTAIN_ENTRIES будет пытаться построить дельту, что
как раз и приводит к таймауту.


П.С. Интересно, а что Вы грузите в таком объеме?

Лично мы - нормы расходов для дискретного производства.
Но у нас как раз таких проблем с CAMA_TABLE_MAINTAIN_ENTRIES не возникает (при предварительном удалении записей).
А RCU_UPLOAD_EXCEL_TO_VTAB напрямую не подходит из-за того, что нужна поддержка версионности таблиц.

На данный момент планируется запускать раз в 10 суток.


Как уже сказали, он работает точно так же. Или примерно так же


То есть? Вначале считывать с CARD_TABLE_READ_ENTRIES и дружно удалять с помощью CAMA_TABLE_MAINTAN_ENTRIES и комитить, а только потом запускать CAMA_TABLE_MAINTAN_ENTRIES для вновь создаваемых записей? Я этот момент не продумывал, он может быть важным?


Спасибо, посмотрю.


Пока что загрузку на сервер приложений и загрузку данных оттуда написал, протестируем и перенесём, а потом буду уже думать над оптимизацией.

Да.

:) Это правда. По крайней мере, в 4.7. Проверьте.

Это неправда
ФМ SAPGUI_PROGRESS_INDICATOR не сбрасывает время диалогового шага в 4.7.

Может, SAPGUI_PROGRESS_INDICATOR в 4.7 время диалогового шага и не сбрасывает, но тайм-аут обходить позволяет: при установленном тайм-ауте в 15 минут программы в диалоговом режиме работали свыше часа, а отдельные экземпляры - до 3-х с копейками часов.

Наверное все-таки дело было не в SAPGUI_PROGRESS_INDICATOR

В общем, работает оно в фоновом режиме, обрабатывает потихоньку (рекомендацию по предварительному удалению сделал), но на таблице, где 93 с половиной тысяч записей (там комбинация двух полей, значит в модуль подаётся в два раза больше строк) он задумался надолго, на несколько часов, так что мы его оставили обрабатывать до следующего рабочего дня.
Вообще, у полей таблиц (в которые выгружаются) номера позиций, комбинаций имеют тип NUMC длиной 5. А это 99.999, так что наша таблица дошла почти до максимума. Может он (ФМ CAMA_TABLE_MAINTAIN_ENTRIES) не предназначен для работы с таким большим объёмом строк?

После 9 часов размышлений система-таки отменила фоновое задание, предварительно послав сообщение CD328 (Transfer table would lead to a duplicate record in CDPOS/CDPOS_UID). Что это значит, и с чего оно может быть? В загружаемых в таблицы вариантов данных дубликатов нет (если в качестве ключа брать внутренний номер таблицы, номер строки/комбинации и название признака). Записей в проблемной таблице 91522 (строк в файле данных в два раза больше, два признака на одну комбинацию, они потом объединяются ведь).

добавление:
Отдельная загрузка таблицы прогрузила её за 41 минуту. Однако если грузить 6 таблиц по очереди (по сути, в коде по очереди для каждой таблицы выполняются считывание CARD_TABLE_READ_ENTRIES, удаление с помощью CAMA_TABLE_MAINTAIN_ENTRIES, комит и добавление новых записей), то увисает. Может система, условно говоря, "перегревается"?

Бампну тему, в надежде, что мне кто-нибудь всё-таки ответит.
Проблема всё та же - таблица (в которой под 100 000 записей) не может прогрузиться в таблицы вариантов. Причём, когда прогружаешь эту таблицу одну, то она прогружается модулем за 40 минут. Однако если загружать по очереди 6 таблиц (5 маленьких и одна большая), то он застревает на этой большой 6-ой таблице на множество часов. А после долгих раздумий вылетает с ошибкой CD328 (Transfer table would lead to a duplicate record in CDPOS/CDPOS_UID). Задание выполняется в фоновом режиме.
Может мне стоит создать для этого вопроса отдельную тему?

А почему таблицы отдельными заданиями нельзя грузить?
Судя по всему, в какой-то группе функций копится "мусор" на уровне глобальных данных...

То есть как - "отдельными"? 23 раза запустить транзакцию?
По сути, программный код просто выполняет в цикле для каждой таблицы один и тот же набор действий:
- считывание старых записей с помощью CARD_TABLE_READ_ENTRIES, удаление их с CAMA_TABLE_MAINTAIN_ENTRIES, коммит
- загрузка новых записей с помощью CAMA_TABLE_MAINTAIN_ENTRIES, коммит
И где-то в промежутке между таблицами, видимо, нужно что-то очищать. Вот только что?


Ну я примерно так и думаю, вот только понятия не имею, где искать источник проблем. Может есть какие-то курсы, документация?

Да.
Делаете отчет с параметром запуска "Имя файла" и 2-й отчет, который в цикле по файлам вызывает 1-й отчет через SUBMIT ... AND RETURN

Через se30 можно организовать анализ памяти

Может этот ФМ поможет?