Как правильно проверять результат выполнения модуля обновлений, если модуль вставляет или апдейтит в таблице БД некоторое количество из внутренней таблицы? Как определить, для каких строк инсерт/апдейт прошел, а на каких строках возникла ошибка?

Возможно, при вызове ФМ такую проверку можно делать в своей формочке, которая указывается в вызове Call function.

Не пойдет. В том и соль, что это модуль обновления, а не RFC-модуль.

Ведите лог

А если чуть подробнее? У меня эта проблема как раз и возникла из-за необходимости ведения документа изменений: в xz_таблицу нужно ведь писать не все записи, переданные в модуль обновлений, а только те, по которым инсерт или апдейт прошли успешно.

модуль обновления Ваш или стандартный ?

мой

собственно, проблема вот в чем: внешняя система передает в САП большой объем строк, которые нужно вставить в таблицу за очень ограниченное время. то есть возможен только пакетный инсерт: INSERT FROM TABLE ACCEPTING DUPLICATE KEYS. Построчное добавление строк с анализом sy-subrc не подходит по соображениям быстродействия. По итогам импорта строк в таблицу нужно отразить добавленные в таблицу записи в документе изменений. в случае с построчным инсертом я проблем не вижу, а вот с пакетным инсертом возникли проблемы.

IMHO если не делать построчно, то никак. Можно разве что проверить количество строк, которые должны были быть добавлены, с тем, что было добавлено:


Вообще если вы используете INSERT ... ACCEPTING DUPLICATE KEYS, то не совсем понятно, какая ошибка может возникнуть. Разве что update termination, но об этом вы скорее всего все равно в вашем модуле не узнаете.

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

И действительно если вы используете INSERT ... ACCEPTING DUPLICATE KEYS то как данные могут не записаться в БД? тут возможны только системные ошибки на уровне БД и соответственно будет дамп.

К стати есть ещё комманда Modify может он вам больше подойдет.

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

А я-то по наивности своей считал, что модули обновлений и LUW нужны для обеспечения целостности данных при внесении изменений в таблицу. Считайте: моя Z-овская таблица раз, CDHDR/CDPOS два: уже хорошо бы удостовериться, что данные добавлись во все таблицы или не добавились ни в одну. Раз вызов документа изменений оформлен как модуль обновления и выполняется с опцией IN UPDATE TASK, мне кажется логичным и добавление в Z-овскую таблицу тоже отложить до коммита.


При исключении первичного ключа и условии ACCEPTING DUPLICATE KEYS никакого дампа не будет. Просто строка в таблицу не добавится. Какая именно - черт ее разберет, потому и вопрос возник.

Действительно по наивности целостности данных вполне можно добиться выполнив вовремя Commit Work, он либо пройдет либо всё откатится.

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

Используйте оператор Modify и таких проблем не будет.

Если в вашей системе ловится ( в моей не ловится)
CATCH SYSTEM-EXCEPTIONS SAPSQL_ARRAY_INSERT_DUPREC = 1.
можно попробовать вставлять без ACCEPTING DUPLICATE KEYS,
логировать строку, вызвавшую исключение и загружать таблицу дальше без ошибочных строк.