Уважаемые коллеги, очень хотелось бы поднять проблему работы формирования статистических и печатных форм на больших массивах информации. Проблема заключается в том, что формирование стат.отчета/печатной формы чаще всего выполняется на всей базе данных. Когда база относительно небольшая - результаты можно получить за вменяемое время. При базах более 50 000 записей формирование этих документов может длится очень много времени. Вполне логичным будет рекомендация перед запуском печатных/статистических форм выполнять поиск - тогда на печать будет подаваться всего часть (и, чаще всего, очень небольшая) записей из базы. Однако, в АРМе Книговыдача невозможно сделать предварительный отбор перед тем, как запускать формирование стат. форм, а как раз на кафедре обслуживания формируется и контролируется большая часть статистики.

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

Не могу сказать ничего определенного по поводу этой идеи...

Александр Иосифович, это действительно является проблемой для всех, у кого базу ЭК и читателей переваливают за 50 000 записей. А у нас сейчас таких пользователей уже несколько десятков. На данный момент приходится перенастраивать таймауты отключения клиентов и каждый раз выполнять сложные запросы, а потом уже по результатам запросов выполнять печать или формирование стат. форм.

Фактически, очень хотелось бы, что бы печать и стат. формы работали по тому же принципу, как ив АРМе Комплектатор:
1. в опросном листе вводятся параметры
2. Выполняется поиск записей (с учетом параметров из опросного листа)
3. Формируется печатная форма по результатам поиска (в ней тоже используются параметры из опросного листа)

Хорошо, подумаем...

В порядке эксперимента предлагается следующее решение.
При создании опросных WSS для табличных форм задействовать неиспользуемый атрибут ПОВТОРЯЕМОСТЬ (третья колонка в редакторе РЛ).
Если соответствующий элемент опроса (подполе) должен участвовать в отборе (поиске), то в качестве этого атрибута указывать префикс для поиска и, если необходимо, признак усечения: например, NKSU=$. Если же элемент не должен участвовать в поиске, этот атрибут должен иметь значение 0 или пусто.
Такое решение связано только с изменением irbisbat_plus.exe (прикрепляю его здесь), который используется в АРМах Каталогизатор и Книговыдача.
Если эксперимент будет удачным, сделаем то же самое для стат.форм и включим в 2019.1.

Александр Иосифович, большое спасибо! Буду тестировать

И каковы же результаты тестирования?