Ограничение выборки перед открытием формы - как лучше сделать?

[SRF]

Цитата:

Сообщение от IKA

Спасибо за пример. Как раз то, что надо!
Хотя сакральный смысл транзакции в InventAdjTransactSelect -> run () мне не ясен (вроде, для врем таблиц ttsbegin - как мертвому припарка, как и проверки на дедлоки). Я так понимаю, просто вслепую шаблоном для runBase->run воспользовались...

+ не совсем не понимаю, почему нельзя было вызвать по menuItemButton этот класс на форме InventAdjTransaction->ButtonGroup->Choose , зачем под кнопкой в clicked пишут prompt() и run() (да и executeQuery на DS можно было бы в классе выполнять)?

Можно, но так реализовали, ведь если у вас будет пункт меню клиентский, а сам класс серверный, то разницы(с т.з. механизмы работы), где писать код по вызову prompt, run, executeQuery - в методе на форме или в методе main собственно нет.

А вот если у вас пункт меню будет серверный, то разница уже будет, как минимум в том, что метод executeQuery придется дергать серверу(доп. взаимодействие клиента и сервера), возможно, что-то придется поменять в передаче временной таблицы.

Цитата:

Сообщение от sukhanchik

Если Вам надо решить задачу с временными таблицами - то вы ее не решите разумным способом за разумное время и так чтобы работало быстро.

Почему? Все зависит от критериев(способ, время) и ожидаемого результата(скорость).

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

Цитата:

Сообщение от sukhanchik

Будете изобретать велосипед и за ядро пытаться решать сколько записей выводить - так, чтобы было быстро для пользователя.

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

Цитата:

Сообщение от sukhanchik

Ну а форма, основанная на постоянной таблице - будет открываться быстро на любом объеме данных - это уже стандартное поведение ядра системы.

Небольшая поправка, не всегда, все зависит от группировок и сортировок используемых в форме.

Цитата:

Сообщение от sukhanchik

Он будет как минимум за счет скорости открытия формы. Да и если использовать класс RecordInsertList для вставки записей - то даже на этапе перелива уже будет выигрыш

Да эффект будет, но если основное время при открытии формы занимает расчет полей, что как я понимаю в данной задаче и является основной проблемой - то почему бы быстро не уменьшить объем рассчитываемых данных ?

Я это к тому (грубые прикидки): что вот форма предположим сейчас открывается 3 часа для 1000 позиций, переделываем на постоянную - получаем скажем 30 минут расчета в пакете, теперь форма для всех позиций открывается 0,5 секунд(но это в случае, если скажем нет необходимости в оперативных данных).

Если мы просто фильтруем рассчитываемые позиции по 10-20, то получаем, что на каждую выборку мы тратим 100-200 секунд, что естественно гораздо больше 0,5, но в тоже время существенно меньше 3 часов.