Forms или OAF (HTML) ?

Forms - можно.

Попытаюсь встрять:

1. "..механизм вызова процедур так устроен, что воспринимает все параметры как DB-side..."

Термин "как DB-side" замечателен ))) Он предполагает, что это не бага, а фича ))) На самом деле все просто. Данное действие не умеет работать с bind-переменными вообще. Просто выполняется переданная ей строка (аналог Forms'овой FORMS_DDL build-in)

Если нужно передать параметры, приходиться строить "динамический" SQL

='begin.... my_procedure(' || :BLOCK1.ITEM1 || ');....end'

Проблемы 2-е:
a) Ограничение длины выражения в персонализациях (в R11 <250 символов, в R12 - не знаю). Сложные выражения банально не влезают
b) "Сложные" типы - типа строки символов (если может быть одинарная кавычка)

В общем, так лучше НЕ делать.

2. "Как вариант, используйте вызов функции, а не процедуры...присваивайте значение функции локальной переменной формы"
+1
Думаю, что пример c SELECT'ом можно несколько упростить ))) Собственно SELECT там и не нужен. Например, для вызова функции FND_PROFILE.VALUE, достаточно просто написать:

=FND_PROFILE.VALUE('APPS_DATABASE_ID')

3."Чтобы БД-коммит не влиял на форму"
+1
IMHO
a) Я бы в ряде случаев посмотрел на автономные транзакции
b) В случае "сложной" логике (api, формирующее документы) - логику реализовал бы в виде Concurrent'а, из персонализации просто инициировал запуск данного процесса.

Для передачи большого кол-ва параметров, я бы сделал свой stored-пакет с глобальными переменнами. И функции "сеттеры".
Через селект проталкивал в пакет нужные нам параметры (возможно через несколько select'ов). Через FORMS_DDL (вызов процедур) - запускал обработку. При кол-ве параметров: > 10-20 - думаю это единственный "читабельный" вариант.

Как я помню, еще одна частая ошибка (проблема) - после ...end точка с запятой не нужна.

1. Я бы всегда делал свой пакет/процедуру "запускальщик". Т.е. в самой персонализации _минимум_ логике.

В реальных проектах: Персонализация - слишком легко доступна для шаловливых ручек консультантов и слишком тяжела для модификации программистом. Нефиг логику работы делать консультанту. Все равно надо привлекать прогера. Т.ч. все "программерское" - в БД. Потом намного легче править. Намного меньше притензий от консультанта - оно "вдруг" перестало работать.

2. После п.1 - все как обычно в сторед-процедуре:

Процедура (автономная транзакция)
FND_CONCURRENT (см. Application Developer Guide)
COMMIT

IMHO

Обычно проблема не в консультантах, а в том, что сложная персонализация становиться "совместным творчеством" - консультант + приблудившиеся программисты. Когда перестает работать - не понятно, кто виноват и что делать. К тому же, MD.050/070 на персонализации пишут редко. Т.ч. и концов не найдешь.

Если четко делить "Персонализация, вызов" - "Сервер сайд, логика и обработка" становиться понятна зона ответственности консультант - персонализация, объекты БД - группа разработки (программисты). Если не происходить вызов (проблемы в персонализации) - притензии к консультанту, если вызов происходит корректно, а работает не корректно - притензии к программисту. Аналогично и перенос (инсталяция) на продакшен БД. Становится понятно, кто что делал и кто что должен перенести. В каких документах фиксировать.

"...В случае, количество консультантов с шалавливыми ручками привышет количество консультантов со здравой головой, как правило персонализацию закрываю паролем, который доверяют только последним...." - ну на тестовой БД, пускай и шаловливыми рученками играются. Не проблема. А на продакшене - вообще нефиг править, пароль должны знать админы и особо избранные товарищи (т.е. 2-3 человека на весь проект). И даже здравая голова тут не при чем. Нужно перенести на продакшен: подготавливаете на тестовой БД, просите админа, перенос (изменение) фиксируется в журнале (документах).