Если в FORMS есть блок, связанный с данными БД, которые пользователь может изменить в FORMS, то
В этом блоке должны быть триггеры ON-INSERT, ON-UPDATE, ON-DELETE, которые должны содержать единственный оператор NULL;. Это для надёжности.
В этом блоке свойство DML Data Target Type Property должно иметь значение NONE. Тоже для надежности.
Перенос данных из формы на сервер БД целиком и полностью выполняется программным кодом, написанным разработчиком.
Перенос выполняется на триггерах
WHEN-VALIDATE-RECORD;
WHEN-VALIDATE-ITEM;
WHEN-CHECKBOX-CHANGED;
(а также некоторые другие - для списков и радиобаттонов - но это экзотика).
Если нет острой необходимости в "досрочном" переносе, то предпочтение для переноса - триггер WHEN-VALIDATE-RECORD.
Для обработки переноса данных пишется специальный пакет в БД ORACLE, например, пакет PKG_PROBLEM_014_FMB.
Запрещено присвоение значения ключевому полю в FORMS из последовательности в свойстве поля Initial Value.
Также запрещено это действие на триггере PRE-INSERT.
Значение ключевого поля должно формироваться на сервере БД в процедуре валидации пакета PKG_PROBLEM_014_FMB и должно явно присваиваться полю блока FORMS в триггере WHEN-VALIDATE... или WHEN-...-CHANGED после успешного выполнения процедуры пакета PKG_PROBLEM_014_FMB.
Если ключевое поле блока находится на NULL канве, то не надо заморачиваться с установкой свойства этого поля ITEM_IS_VALID.
Если при выполнении процедуры пакета PKG_PROBLEM_014_FMB. возникла ошибка(нарушены бизнес-правила) - она должна быть на русском понятном языке и должна быть отображена в форме.
Например, в триггере WHEN-VALIDATE-RECORD должен присутствовать код:


Напоминание разработчику: вызов raise form_trigger_failure; в любом триггере валидации запрещает пользователю покинуть поле или запись до тех пор, пока ошибка при валидации не будет устранена.
После завершения переноса валидируемой строки или элемента формы статус строки помечается QUERY.
Например:


Если надо удалить строку, то перед удалением ее статус помечается NEW. Например, в триггере KEY-DELREC:


Таким образом в любой момент FORMS понимает, что серверу приложений не надо заниматься переносом данных в БД и не пытается ничего перенести.
Подтверждение изменений данных COMMIT - в триггере KEY-COMMIT формы, а также в триггере WHEN-WINDOW-CLOSED и KEY-EXIT формы.
Разработчик должен отслеживать факт: вносил ли пользователь в форме изменения, которые пока не подтверждены и при попытке выхода из формы задать вопрос о необходимости подтверждения сделанных изменений.
Перед подтверждением изменений настоятельно рекомендуется выполнить validate(form_scope);
Если валидация выполнена успешно, то вызывается pkg_problem_014_fmb.do_commit, где происходят проверки бизнес-логики и окончательный коммит.
А на триггере POST_FORM выполняется


Если при валидации элемента формы необходимо отобразить измененные данные в нескольких записях (в триггере WHEN-VALIDATE-ITEM есть ограничения, которые не позволяют выполнять некоторые действия,
например нельзя выполнять EXECUTE_QUERY), то допускается запуск таймера.
Если поле блока, расположенное на какой-то канве, было изменено программно, надо немедленно установить свойство ITEM_IS_VALID в значение PROPERY_TRUE (программно валидировать).
Если это поле на NULL канве - то не надо заморачиваться ITEM_IS_VALID.

Остается открытым вопрос о CALL_FORM.
О CALL вызове другой формы, в которой также могут происходить изменения данных БД.
О том, что COMMIT в вызываемой форме может привести к нежелательной фиксации данных в вызывающей форме.
Но это легко решаемый, вопрос, имеющий очевидное решение..
Рекомендации по этому вопросу будут сформулированы при наличии заинтересовавшихся.

Также по понятным причинам не рекомендуется пользоваться OPEN_FORM(...NO_SESSION...)(default).