Есть собственноручно написанная программа (простенькая) по загрузке данных в таблицы вариантов (через CAMA_TABLE_MAINTAIN_ENTRIES). Программа забирает данные из файла. Программа работает слишком долго из-за большого объёма данных (может можно как-то оптимизировать?) и даже вылетает по таймауту. Решено было запускать в фоновом режиме. Но GUI_UPLOAD для загрузки файла в фоновом режиме не работает. Какие есть альтернативы?

Загружать файл на сервер

Посмотрите Вашу программу в данных транзакциях se30 st05 может поможет

А попробуйте поиском воспользоваться, тема поднималась миллион раз

А каким образом загрузить фай на сервер приложений?

Загружать по 1000 записей, делать commit, вылетать не будет.

Я грузил по 5000 записей, несколько таблиц успело загрузить, потом всё-таки вылетело на таблице, где записей было где-то под 100'000 (загружал по 5000). Попробую по 1000

Я так понимаю, с помощью OPEN DATASET и прочих dataset-команд можно загрузить файл на application server, если есть право записи?


Спасибо, попробую.

Периодические обновление статуса с помощью ФМ SAPGUI_PROGRESS_INDICATOR, снимает ограничение по таймауту. Может и не придется грузить файл на сервер, а просто впоследствии оптимизировать код.

Это ложь.


Оптимизировать всегда полезно.

Вы слишком категоричны, давайте как нибудь попроще.

http://sapboard.ru/forum/viewtopic.php ... 89&start=0

оффтоп конечно. Если я правильно понимаю, счетчик обнуляется при освобождении процесса или передачи управления. В этот момент происходит неявный commit work.
Таких случаев не так много:

There are four cases in
which work processes trigger an implicit database commit:
• When a dialog step is completed, control changes from the work
process back to the SAPgui.
• When a function module is called in another work process (RFC).
Control passes to the other work process.
• When the called function module (RFC) in the other work process
ends. Control returns to the calling work process.
• Error dialogs (information, warning, or error messages) in dialog
steps. Control passes from the work process to the SAPgui.

+ явный commit work

Очевидно раньше ФМ SAPGUI_PROGRESS_INDICATOR делал что-то из этого?

А по теме:
Изучите se30 из-за чего тормозит. Как я понял число записей ~100.000 - на таком объеме будут критичны вложенные циклы и read без table key или binary search.
Кстати непонятно, зачем грузить через этот ФМ, напишите проверку ключей и inset\update. Например SM30 на большом объеме нереально тормозит (неудачный цикл с проверками всех записей при добавлении очередной)

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

Для разовой загрузки не стоит конечно. Проще действительно сделать двухшаговую обработку - сначала файл сохранить на аппликейшн, а потом в фоне запустить сохранение. Нюанс - если аппликейшнов несколько то надо либо выбрать для обработки именно тот, на котором сохранен файл либо договориться с базисниками куда можно сложить файлы, чтобы они были доступны со всех серверов.
Если загрузка частая и данные, я подозреваю однотипные, ФМ можно упростить

для загрузки таблиц вариантов есть стандартный отчет:

RCU_UPLOAD_EXCEL_TO_VTAB

попробуйте загрузить с его помощью.

Так он тоже использует ФМ CAMA_TABLE_MAINTAIN_ENTRIES, поэтому быстрее работать не будет.
Попробуйте поднять производительность с помощью использования таблицы БД, если будут выполнены ограничения на содержимое таблицы вариантов