Весёлый,

В этом случае встроенные процессы нужно переписать.

Или используете встроенные атрибуты без использования apex_item => сможете привязать процесс к tabular form и там написать нужную обработку (с 4.1).

Или пользуетесь только apex_item => пишите обработку на g_f коллекциях.

Весёлый1. Каким образом можно переписать встроенные процессы?
Удаляете стандартные, пишите свои, с insert, update, delete и т.д. запросами.
Данные берете или из g_f или или обращаетесь по алиасам столбцов, в зависимости от указанного выше способа

ВесёлыйКаким образом обращаться после этого к [row selector]?
Я так понял, вам эта информация нужна только в процессе обработки, delete из одной таблицы, insert в другую, скажем, пишите тогда соответствующий процесс с insert и delete.


А вот если вы эту информацию не планируете хранить в таблице, и она вам нужна где-то потом,
тогда в этом же процессе можно записать в её в коллекцию, примерно так:
14576693
Там про validations, с процессом тоже самое, привязываете процесс к Tabular Form, обращаетесь по алиасам, пишите в коллекцию,
потом можно будет к этой информации обращаться через вьюшку apex_collections

Или, если у вас apex_item, из g_f можно по аналогии записать в коллецию

ВесёлыйНе смог понять, как привязать процесс к [row selector], поэтому создал apex_item.checkbox2(1, RowID)
Так же через g_f он и работает, если переписываете его через apex_item, тогда и обработку нужно переписывать, чтобы кучу всяких проблем в будущем исключить.
А обращаться также через g_f можно, тут когда-то давно приводил примеры 11041925

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

Весёлый,

авторА, т.е. под переписыванием имелась в виду замена стандартных своими, а не их редактирование? :)
Если вы хотите переписать логику row selector, тогда и процесс нужно переписывать.

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

Можно поподробней, почему? :)
Из-за сложности сопровождения

Во-первых, ломается после апгрейдов (индексы смещаются)
Во вторых, может позвонить заказчик, и сказать: нужно добавить такой-то столбец, или поменять порядок столбцов, но высока вероятность, что разработчик, который этим займется, сломает что-нибудь, причем в самом неоржиданном месте может быть обращение к g_f, уже не говоря, о количестве индексов, которые придётся поменять, забудешь в одном месте индекс поправить - появятся новые баги и т.д.

Весёлый,

т.е нужно, чтобы checkbox для разных request работал и для заполнения, и для удаления, я так понял.

А в базе что происходит, эта операция только на форме, или заполнение идет сразу в таблицу под tabular form?

ВесёлыйСразу в таблицу. А для чего может понадобиться делать только на форме?
Для заполнения :)

Тогда проще, apex_item не нужен, коллекции тоже.
Привязываете процесс к tabular form, там обращаетесь к стандартному checkbox через алиас столбца,
в зависимости от request (нажатой кнопки) написать или insert (заполнение), или delete (удаление).
Стандартный multi row delete соответственно отключить.

SvDevСтандартный multi row delete соответственно отключить.

или его даже его не обязательно отключать, если у вас стандартный checkbox, достаточно, чтобы он выполнялся на свою кнопку (удалить).
SvDevПривязываете процесс к tabular form, там обращаетесь к стандартному checkbox через алиас столбца,
А этот привязать к своей кнопке (заполнить)

ВесёлыйSvDev, а, в этом плане... Нет, возможность заполнения по одной строке тоже присутствует.
А как обращаться через алиас столбца? :-[
При создании процесса, там есть возможность привязать его к tabular form (с 4.1)

В частности для row selector см

APEX$ROW_SELECTOR, APEX$ROW_STATUS

Весёлый,

Для For Created and Modified Rows выделение row selector не должно считаться изменением строки.

Поэтому All Submitted Rows Execution Scope выбираете, дальше для каждой строки смотреть :APEX$ROW_SELECTOR, null или не null

Весёлый,

Он сам их все пройдет, сколько отправлено строк, столько и вызовется раз процесс...

Весёлый,

SvDev,

т.е. в where дописать, не с компьютера пишу

Весёлый,

id - столбец, по которому вы идентифицируете строку таблицы, primary key или rowid не важно
column_name - алиас столбца таблицы в tabular form, который сабмитится (т.е. тип должен быть hidden / text edit / и т.д. ), и который хранит соотв. значение

Делайте rowslelector самым первым столбцом, RowID = hidden - вторым
Раз используете RowID, стандартные процессы тоже делайте на него
В столбцах должны быть указаны source -поля таблицы

Если не получается, пересоздате табличную форму мастером, он сам сделает как надо

Весёлый,

Reference Table Owner

... ,
Reference Table Name
Reference Column Name

Весёлый,

Скорее всего или первые 2 столбца не в том порядке, или от apex_item не избавились где-то, но это все неважно, т.к. пересоздание формы решит любые проблемы - там ведь у вас всё стандартное используется, я так понимаю, теперь.

Весёлый,

Значит должны уже были разобраться после каких конкретно действий они появляются

У вас где-то элементарная ошибка

Вы бы лучше source из запроса того столбца приложили и скриншот со страницы report attributes всех столбцов

т.е. нужен:

1. полный код запроса под формой
2. скриншот со страницы report attributes всех столбцов

или сделайте пример на apex.oracle.com, логин и пароль от workspace приложите

Весёлый,

Посмотрел, если тип табличной формы на основе ROWID, то тип столбца ROWID выбирается Standard Report Column.
В процессе update делайте where не по rowid, а на уникальные столбцы (например, primary key)