Добрый день.

Есть Z-таблица с большим количеством записей (столбцов тоже прилично). Нужно сделать инструмент который сможет редактировать данные. Просто ракурс ведения не удобен т к я не могу ограничить кол-во записей которые нужно исправить.

Нужно было быстро, поэтому сделал так.
1) Сделал отчет который выбирает данные по заданным критериям и сбрасывает их в мемори ид. Потом вызывает ракурс ведения.
2) Сделал ракурс ведения и в нем вместо стандартной выборки из БД сделал чтение из мемори ид.

Все работает, но мне интересно есть ли более стандартный метод? Т е можно ли как-то стандартно ограничить набор данных который в ракурс ведения попадет?

В ракурсе необходимо создать подмножество полей которые будут задавать ваш селект. Для этого проставьте в закладке Поле для необходимых полей атрибут S.

Вполне можно
1) в самом ракурсе есть возможность фильтрации значений
2) есть возможность создать ракурс указав что какие-то его поля используются для образования подмножества. В этом случае при попытке просмотра\редактировании данный в диалоге будут запрашиваться значения указанных полей.

Из чистого любопытства - по-прежнему при вызове ракурса блокируются все записи таблицы? Это, пожалуй, самый неотвратимый минус стандартного диалога ведения...

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

UPD. Вы правы - записи блокируются все.

Спасибо. Но работать с этим неудобно. Юзеры меня не поймуть ... а то и распнут.
Оставим все как есть.

Ракурс ведения можно вызвать с помощью ФМ VIEW_MAINTENANCE_CALL.
В параметр dba_sellist можно передать фильтры для таблицы, причем фильтровать можно любые поля, а не только те, что отмечены как S.

Из минусов: информация о фильтрах никак не отображается в ракурсе; при создании новых записей фильтры так же не учитываются.

Можно зарегестрировать событие для генератора данного ракурса (помню что-то, связанное с блокировкой данных), к сожелению его не изучал, утверждать не берусь, но скорее всего оно должно дать возможность пользователю переопределить область блокировки, прочитав таблицу критериев отбора. Работал с событиями проверки полномочий, инициализации, пред и пост сохранения и выбора данных БД, оганичения даты (для "временных" ракурсов) и удаления записи, отрабатывают на ура.

P.S. Обязательно проверю
P.S.S.
Экран выбора фильтров действительно содержит по умолчанию поля, отмеченные S, но с помощью стандартной опции экрана выбора можно добавить любые другие поля данного ракурса в группу фильтров

ФМ VIEW_MAINTENANCE_CALL - Его и использую.
Завтра буду проверять как можно в dba_sellist сажать данные из select-options при помощи ФМ VIEW_RANGETAB_TO_SELLIST. Если срастется то от мемори ид откажемся и будет нам щастье.

UPD. Спасибо Rokhay за подсказку. Я про dba_sellist забыл потому что не знал.

UPD. ФМ VIEW_RANGETAB_TO_SELLIST подошел на отличненько

Поднимаю тему из запыленных полок.
Если в select-options задать значение в исключении, то VIEW_MAINTENANCE_CALL падает в дамп.
Анализ выявил что VIEW_RANGETAB_TO_SELLIST возвращает лишнюю скобку.