Задача стоит такая.
Необходимо сделать для новостного сайта выгрузку последних 5-ти (или n) введенных документов в базу данных, где бы присутствовал полнотекст (т.е p(v951) давало true).
Причем, желательно, чтобы это была одна строка cgi-ссылка, которая давала бы список, наподобие:

[irbis64.medlib.tomsk.ru]

Было сделано:
Словарь по наличию полнотекста С особыми условиями, вычитания по дате ввода:

907 0 if p(v951) then (if v907^a<>'' then'DP-FT=',f(val('100000000')-val(&unifor('Av907^a#1')),8,0),|%|d907 fi/) fi

Сделан блок для вывода для новостного портала данных:
=============================================
Блок ini Web-ИРБИСа:
[ELRES_OUT]
#для экспорта для портала медицинского выгрузки всякие
FRAMES=D:\Program Files\Apache Software Foundation\Apache2.2\cgi-bin\irbis64r_12\Frames\Search_forms\
ShowFrames=header_out.frm, standart_out.frm,footer_out.frm
SearchFrames=RESULT
DictionryFrames=RESULT
DBName=BOOK
DICT_FORMAT=autocomplete
EXTPREF=<b><font color=red>
EXTPOST=</font></b>
MIN_COLOR_COUNT=7
#HTTP HEADERS
ContentType=
Content-Base=
Content-Encoding=
Content-Language=
Content-Location=
Content-MD5=
Content-Range=
ETag=
Expires=
Last-Modified=
Content-Disposition=
===========================

Сделал отдельный словарь (см. выше, DP-FT=), но вывод результатов идет в последовательности такой, как они идут по mfn.
Можно ли как-то сделать вывод результатов в обратной последовательности относительно их расположения в БД?
Может есть какая каманда незадокументированная, или мне в документации "не по глазам"?

Пробовал "играть" со словарем, но ничего не получается, т.к. если результатов много больше 5-ти, то показывает, все равно по mfn.

В CDS/ISIS была такая команда, чтобы показывать словарь обратно относительно mfn и она настраивалась.

Просто результаты поиска всегда будут выводится в том порядке, в котором они занесены в БД. Для того, что вы хотите, нужно использовать сортировку. Она у вас в ссылке присутствует:

S21SRW=GOD
S21SRD=DOWN

Создайте себе новую сортировку по тому же принциппу, что и в файле инверсии.

Спасибо, все бы хорошо про сортировку но:
1. Она (сортировка) работает от единственного на весь Web-ИРБИС ключа в ini-файле. И управлять ей для конкретного случая в БД (кол-во значений, при котором сортирует) невозможно.
2. У меня результат запроса более 2000 записей.

Абсолютно неэффективно с точки зрения использования вычислительных ресурсов.

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

1. Про первый пункт ничего не понял. Сортировка включается в самом запросе на выводе. Там она может быть любой. Или я что-то недопонимаю?

2. Ну будет отрабатывать чуть дольше, а что тут поделаешь? Вы ведь не 2000 документов за раз выводите ,а гораздо меньше, так что все равно основное время будет тратится на отрисовку биб. описаний, а не на сортировку.

> 1. Про первый пункт ничего не понял. Сортировка включается в самом запросе на выводе. Там она может быть любой. Или я что-то недопонимаю?

В ini файле irbis_server.ini есть параметр, который ограничивает кол-во, чтобы не перенагружать процессор.

MAX_SORT_COUNT=1000

Вот это и есть ограничение, при превышении которого сортировки нет. При этом этот параметр один для всего ИРБИСа, а я его не хочу менять для других баз данных, чтобы не было глупостей от пользователей.

Поставил MAX_SORT_COUNT=3000

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

Поспрашиваю Александра Иосифовича в Крыму, а то ему скучно на юбилейной будет ;)

А если действительно задействовать CGIFLK? Можно попробовать сделать систему адаптивной, что бы не нагружать сервер лишний раз. Например так:

делаем запрос на поиск документов, введенных за последнюю неделю

(<.>DP=20130415<.>[...]<.>DP=20130420<.>)

даты подставляем сегодняшнюю как конечную, а предыдущую выбираем с помощью юнифора

&uf('3B'&uf('3')'/-N')

где N - постепенно увеличивается от 5 до ... до тех пор, пока запрос из юнифора

&uf('+3G…

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


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

Вот пример такого скрипта:

/*Вторая дата в промежутке, первая дата - сегодняшняя.
&uf('+7w1#'&uf('3B'&uf('3')'/-10')),
/*цикл выполняется до тех пор, пока количество ответов меньше 10, но можно соорудить и более сложные условия выхода из него
(if val(&uf('+3SOKIO,0,','|','(<.>DP='&uf('ag1#1')'<.>[...]<.>DP='&uf('3')'<.>)','|',','))<10 then 

   /*количество ответов все еще меньше порога, значит меняет количество дней, на которое надо отступить назад
   &uf('+7w2#'f(rsum(&uf('ag2#1'),';10'),0,0)),
   /*высчитываем дату с новым порогом дней назад
   &uf('+7w1#'&uf('3B'&uf('3')'/-'&uf('ag2#1'))),
   /*для наглядности выводим количество дней, на которое мы отступили назад, в работающем скрипте это не нужно
   &uf('ag2#1')

else 
   /*наконец-то запрос показал, что количество записей больше порога
   /*выводим окончательный текст запроса, который можно поместить в параметр S21ALL
   '(<.>DP='&uf('ag1#1')'<.>[...]<.>DP='&uf('3')'<.>)', break 

fi/)

У меня на базе в 60 тысяч записей скрипт отработал за 32 милисекунды и вывел результат работы в Веб. Вот что увидел на вебе

10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 170 180 190 (<.>DP=20121014<.>[...]<.>DP=20130422<.>)

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

Спасибо за скрипт, буду думать.