Добрый день!

Подскажите, пожалуйста, что означает ошибка "Нет ответа на запрос" при формировании выходной формы в Комплектаторе?

Спасибо.

Значит вы задали такие параметры в опросном листе, что по ним не нашлись записи.
Если точнее, то прикладывайте картинку и называйте версию

Спасибо!

Однако, при проверке запроса из srw-файла в редакторе форматов он возвращает данные по всем нужным записям.

В чём ещё может быть проблема?

Прежде чем выдать ошибку он думает около 10 минут. Может там таймаут какой-то стоит?

Версия Комплектатора Ирбис.64 2012.1

В АРМе Комплектатор запрос формируется на в файле srw, а в файле Seltab64.par. Картинку можете приложить?

Держите картинку, но не уверен, что она вам поможет.

По запросу из seltab64.par данные тоже находятся:
if p(v910) then '"NKS2=',v910,'$"' fi

Подтверждение этому - на второй картинке.

Кроме того, ошибка выдаётся только для этого конкретного КСУ, для остальных отчёт формируется успешно.

Меня не покидает ощущение, что это как-т связано со временем работы запроса.

Вы эту таблицу сами сделали? В дистрибутиве таких нет.
У сервера есть действительно параметр в irbis_server.ini

#максимальное время обработки запроса
PROCESS_TIME_LIVE=15

Попробуйте увеличить.

Да, мы сами сделали эту таблицу.

Помогите, пожалуйста, понять, с чем может быть связано экспоненциальное увеличение времени работы отчёта.

Отчёт выводит список инвентарных номеров КСУ выбытия (из поля 940) с группировкой по году поступления (940^c). Соответственно, в отчёте два ключа сортировки - 1) год поступления и 2) инв. номер и вся остальная информация по нему (автор/заглавие, цена и пр.)

Обнаружилось, что время работы отчёта очень сильно зависит от количества списываемых инвентарей одного издания. Вот такая получается динамика:
11 повторений поля 940 - отчёт формируется за 3 пробега кошечки
12 повторений - за 8 пробегов
13 повторений - за 19 пробегов

Налицо экпоненциальный рост с коэффициентом больше 2. Не стоит и мечтать дождаться результатов при списывании 20 инвентарей из одного издания.

При этом от общего кол-ва списываемых инвентарных номеров в КСУ время не зависит. Их может быть и больше 100 - отчёт формируется очень быстро, если в каждом конкретном издании их не больше 10.

С чем может быть связано такое странное поведение? Где посмотреть? Куда копать? Может это известная какая-нибудь проблема?

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

Вот такие форматы.

Если бы был бесконечный цикл, то отчёт вообще бы не формировался верно? А у нас он формируется, вопрос только во времени работы.


[KeyOptions]
4
1
(v940^C*0.4/)
100
1
if v940^v:&unifor('Av991#1') then (if p(v940) then if v940^a:'6' then if v940^v=&unifor('Av991#1') then if p(v940^w)then else '^aB=',if p(v940^b) then if v940^b.1='0'or val(v940^b.1)>0 then f(val(v940^b,' 0'),8,0) else v940^b.1,if v940^b*1 <>''then f(val(v940^b*1),7,0) fi fi else f(val(v940^h,' 0'),8,0) fi,'^3'mhl,v940^b,if a(v940^b)then v940^h fi,mpl,'^4'mfn,'^C'v940^C*0.4,'^I'v910^I,'^5'if p(v940^e) then f(val(v940^e,' 0'),0,2) else if val(&unifor('Av10^d#1'))>0 then f(val(&unifor('Av10^d#1'),' 0'),0,2) else '0.00' fi fi,'^6'if p(v940^c) then if &unifor('Kizc.mnu|'v940^c.6)<>'' then f(val(&unifor('Kizc.mnu|'v940^c.6)),0,5) else if &unifor('Kizc.mnu|'v940^c.4)<>'' then f(val(&unifor('Kizc.mnu|'v940^c.4)),0,5) else if val(v940^c.4) > 1947 then '1.00000' else f(val(&unifor('Kizc.mnu|1947')),0,5) fi fi fi else '1.00000' fi, if '|z19|z17|z18|z4|z5|z9|z16|z7|z14|z15|z20|z8|': s('|', &uf('Av106^a#1'), '|') then '^7' &uf('Av215^a#1') else '^71' fi fi fi fi fi/),(if p(v940)then if v940^v=&unifor('Av991#1') then if v940^a:'6' then else if val(v940^x,' 0')-val(v940^z,' 0') >0 then '^aB=',if p(v940^b) then if v940^b.1='0'or val(v940^b.1)>0 then f(val(v940^b,' 0'),8,0) else v940^b.1,if v940^b*1 <>''then f(val(v940^b*1),7,0) fi fi else f(val(v940^h,' 0'),8,0) fi,'^3'mhl,v940^b,if a(v940^b)then v940^h fi,mpl,'^4'mfn,'^C'v940^C*0.4,'^I'v910^I,'^5'if p(v940^e) then f(val(v940^e,' 0'),0,2),|/yec|d940^1 else if val(&unifor('Av10^d#1'))>0 then f(val(&unifor('Av10^d#1'),' 0'),0,2),|/yec|d940^1 fi fi,'^Z'if p(v940^z)then f(val(v940^x)-val(v940^z),0,0) else f(val(v940^x),0,0)fi,'^6'if p(v940^c)then if &unifor('Kizc.mnu|'v940^c.6)<>''then f(val(&unifor('Kizc.mnu|'v940^c.6)),0,4)else if &unifor('Kizc.mnu|'v940^c.4)<>''then f(val(&unifor('Kizc.mnu|'v940^c.4)),0,4)else f(val(&unifor('Kizc.mnu|1980')),0,4) fi fi else'1'fi,'^7'f(val(v940^x,' 0')-val(v940^z,' 0'),0,0) fi fi fi fi/)fi
*****

Если упростить второй формат, например, до такого:
(if p(v940) then if v940^v=&unifor('Av991#1') then v940^b fi fi/)

То отчёт по понятным причинам формируется пустой, но работает также долго.

У вас два уровня сортировки. На первом уровне вы извлекаете все подполя 940^C? А что на втором? Что вы хотите прописать под каждыи значением 940^C? Меня смущает множественность второго ключа. А что в файле Sortlst1.txt в workdir?

Что отображается в отчёте, я уже писал:
Отчёт выводит список инвентарных номеров КСУ выбытия (из поля 940) с группировкой по году поступления (940^c)

Форма прилагается.

Файл Sortlst1.txt конкретно для этого КСУ формируется размером 107 мегабайт и содержит 152 тыс. строк! Тоже прилагается.

По этому КСУ в одном издании содержится максимум 14 повторений поля 940.

Думаю, стоит объединить два цикла в один
if v940^a:'6' then ... else ...

Огромный файл Sort, отсюда и время выполнения.
Вы форму строите на заголовках? Думаю, что можно построить ее более оптимально. Во-первых, 1 ключ сортировки, а в нем сделать подполя для разных элементов, которые исполбзуются в таблице.