Передача датасорса в класс (пакетный режим)

[Stitch_MS]

Я правильно понимаю, что вы можете собрать RecId выделенных записей и сохранить их в Set, (который легко пакуется/распакуется), не не хотите этого делать? Если да, то что не так с использованием Set-a?

[DesparioN]

Проблема в том, что set будет формироваться на клиенте, т.е. пользователю придется ждать пока он сформируется. По возможности хотелось бы все перенести на сервер.

[Stitch_MS]

А каким образом пользователи вручную помечают столько записей, что даже просто считать их стандартной конструкцией типа

for (custTable = _formDS.getFirst(true);
         custTable;
         custTable = _formDS.getNext())
    {

занимает слишком много времени?

Они сначала фильтруют записи в гриде, а потом кликают в верхнем левом углу, чтобы выделить всё? Тогда уж надо запрос из формы копировать, а не выделенные записи.

[DesparioN]

В общем случае функция запускается по 1-2 записям и на клиенте она отрабатывает достаточно быстро.
Но раз в определенный промежуток времени выделяется большой объем (последний раз было более 100к).

Хотелось сделать единый входящий параметр и максимально уменьшить время ожидания пользователя.
Просто раз это можно делать на клиенте, то подумал что и на сервере должно быть не сложно.

[Stitch_MS]

Цитата:

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

... выделяется большой объем (последний раз было более 100к)...

Каким образом? Что конкретно делает пользователь руками, чтобы выделить 100к записей?

[DesparioN]

"сначала фильтруют записи в гриде, а потом кликают в верхнем левом углу, чтобы выделить всё"

[gl00mie]

Цитата:

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

Проблема в том, что set будет формироваться на клиенте, т.е. пользователю придется ждать пока он сформируется. По возможности хотелось бы все перенести на сервер.

Если вас так волнует, что пользователи будут ждать заполнения Set на клиенте, не давайте им вообще выделять записи через Grid - пусть запускают нечто (периодическую операцию, например) и через штатный механизм фильтрации (кнопка Выбор, расширенный фильтр, все дела) отбирают записи, подлежащие обработке. Крыжить записи на форме - это для случаев, когда записей мало, а критерии выбора трудно формализуемы. Если пользователи отфильтровывают записи и потом выделяют их все, то это - избыточный шаг, они даже не видят все записи, которые хотят обработать, потому что на форму для отрисовки Grid тянется лишь несколько десятков записей из выборки.
Выделять все записи для обработки через Grid - это все равно что слать в СУБД запрос на выбор 100500 записей, получать их по сети, потом куда-то там сохранять их уникальные идентификаторы, передавать их обратно по сети в СУБД и слать запрос "обнови как записи вот с такими идентификаторами таким-то образом". Так ведь никто с СУБД не работает - все стараются сразу послать запрос "обнови таким-то образом записи, которые удовлетворяют таким-то критериям".
Тем более это актуально в случае пакетной обработки: обычно форму клиент открывает на одном сервере, а пакетная обработка запускается на другом, и между ними нужно передать данные, что именно следует обрабатывать. В этом плане запаковать запрос с критериями фильтрации проще и быстрее, чем запаковать Set/Map с идентификаторами каждой записи.

Если же записей обычно немного, то посмотрите на штатный подход передачи их с формы в класс-обработчик - FormLetter::getFormRecord().