КурдльХотелось решить проблемы "клиента" - на самом "клиенте".
Ты же так и не ответил, я предложил самое простое решение.
Скрыть у юзвера кнопку удалить.

КурдльblkangelТы же так и не ответил, я предложил самое простое решение.
Скрыть у юзвера кнопку удалить.
И что, оставить на форме чекбоксы, которые непонятно для чего?
Тогда у тебя стандартные апексовые процессы будут работать, и не нужно будет придумывать велосипеды...

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

КурдльblkangelКурдль,
Кстати, а как же у тебя не у юзверов есть возможность удалить строки?
Такой возможности нет. Строки в табулярной форме соответствуют метрикам аудита. Удалить можно только весь аудиторский отчет целиком. Добавлять строки тоже нельзя: сколько метрик - столько строк.

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

КурдльPetro123Курдль,
вариант фальшивого поля в самом SQL запросе не проходит? Или было?

Коллеги!
Я выкрутился из ситуации триггером. Но при желании мог бы кастомизировать процесс MRU.
Я ж написал, что я его вкурил :) Да, будут лишние обращения к БД и риски, связанные с использованием недокументированной функции.
Простейший случай (когда не надо ничего вычислять внутри процесса и не обязательно выявлять изменившиеся строки) - я изобразил в коде.
Желающие могут дополнять его "обвеской". Мой пост 17201428 можно считать подсказкой тем, кто захочет это сделать. Далее мы только засоряем тему, отдаляясь от целей форума - помогать друг другу находить правильные решения :)

Цель не оправдывает средства... Либо я не до конца ее понял.

КурдльblkangelЦель не оправдывает средства... Либо я не до конца ее понял.

Ок! Допускаю, что я мог заморочиться там, где выход гораздо проще и прозрачнее (для профессионалов).
Для чистоты экскреперимента сформулирую простейшие абстрактные условия.

Существует таблица TABLE с полями А и В.
Пользователю в виде Tabular Form представляется интерфейс для изменения подмножества записей TABLE, посредством редактирования поля А.
После утверждения изменений (нажатия кн. SUBMIT) перед COMMIT-ом должно заполниться поле В именем пользователя (:APP_USER).
Каково простейшее решение?
Построчный триггер, со стандартными процессами в апекс.

КурдльНо сначала я нашел отсылки к документации по старым АПЕКСам. Там была довольно изящная документированная функция обработки множества строк в табулярной форме. Покопался в новом АПЕКСе и понял, что триггер - предпочтительнее.

Я открою тебе тайну, интерактивный и стандартный репорт можно менять и сохранять :)
Функция работы с табулярной формой, ничто иное как создание массивов по индексам F01-F50, передача этих массивов в pl/sq.
А дальше, крути верти как хочу
Вот только остается понять, чем же наполняет этот массив Апекс и каким образом. :)
Как говорит Petro123, удачи :)