Передо мной встала тривиальная задача: добавить дополнительный критерий отбора (специализацию) для вывода сведений по книгообеспеченности. Я был шокирован тем, что увидел в формате файла сортировки Tabkow.srw. Мне потребовалось около часа, чтобы разобраться в нём и ещё 6 часов выходного дня я потратил на то, чтобы нужным образом его изменить.(!!!)

if p(v691) then if ref(mfn,(if p(v691) then if 'v991':v691^a or (not('v991':'^a')) then if 'v991':v691^b or (not('v991':'^b')) then if 'v991':v691^d or (not('v991':'^c')) then '1;'fi fi fi fi/)):'1'

<для наглядности, код разделён мной на две части(СКЕ)>

then v461^x,v461^b,&unifor("9"d461^c,&unifor('+S0',v461^c)),v700^a,v700^d,", "v700^g,if a(v700^g) then" "v700^b fi,v710^a,v200^v,&unifor("9"d200^a,&unifor('+S0',v200^a)),if v920:'NJ'then ref(l(|I=|v933),&unifor("9"d200^a,&unifor('+S0',v200^a)),|/ |v200^f),v934,"/"v935,"/"v936 fi,v963^x,&unifor("9"d463^c,&unifor('+S0',v463^c)),v463^j,v463^v,v463^h,v463^k fi fi


Чтобы стало понятно, насколько нелепым является этот формат, разберу его "особенности" по порядку.
1.Конструкция "ref(mfn,", где mfn - номер текущей записи абсурдна.
2.Использование громоздких конструкций отрицания ((not('v991':'^c') вместо a(v991^c)) совершено не оправдано. Даже, если по каким-то причинам функция a() не могла быть применена, гораздо проще выглядело бы сравнение с Null(...or v991^c=''...).
3."Литерал - это строка символов, заключенная в соответствующие ограничители, которая вносится в выводимый текст в таком виде, как она приведена в формате.", - написано в инструкции. В данном случае, литералом стала метка поля, данные из которого извлекаются, а не "строка символов,... которая вносится в выводимый текст в таком виде, как она приведена в формате". Особенно неуместными выглядят здесь безусловные литералы.
4.Не совсем понятно, зачем осуществляется двойная проверка данных в поле 691(if p(v691) then if ref(mfn,(if p(v691)). Это ровным счётом ничего не даёт.
5.Зачем к единице потребовалось добавлять точку с запятой('1;')?
6.Зачем использовать сравнение с конкретным значением(....fi/)):'1'), когда функция ref может возвращать только одно значение - '1;'. Было бы проще использовать ....fi/)):'1'<>''?
7.Каждое подполе 691 (691^a, например) сравнивается со всеми данными поля 991, и это вызывает серьёзные ошибки. Есть имеются факультет РЭ и кафедра УФРЭ, то вместо отбора по факультету будет осуществляться отбор по названию кафедры. Тем более, страшно представить, какие результаты попадут в отчёт, если аббревиатура факультета состоит из одной буквы, и эту букву включают названия разных факультетов...
8.Генерация отчёта осуществляется после непосредственного "просмотра" всей базы библиографических описаний. При больших объёмах базы и слабых машинах, операция может занять до 7 минут. Это время можно было бы уменьшить в сотни раз, если бы разработчики предусмотрели поиск по словарю.(В новых формах, сгенерированных при помощи Генератора табличных форм, с этим дело обстоит ещё хуже)


Пункты - 1-4 дают представления об ухищрениях, к которым автор формата был вынужден прибегать, чтобы обойти какую-то хорошо известную ему ошибку. Комментарии к пунктам 4-8 излишни. Этим "странностям" нельзя найти рациональное объяснение. После того, как я увидел этот формат, мне стало ясно, почему С.М.Дунаевская отказалась отвечать на вопросы М.Панаеа относительно структуры табличных форм старого типа...

УАЖАЕМЫЕ РАЗРАБОТЧИКИ! ВАШИ "МАЛЕНЬКИЕ ТАЙНЫ" ОБОРАЧИАЮТСЯ БОЛЬШИМИ ПРОБЛЕМАМИ ДЛЯ ТЕХ, КТО ВЫНУЖДЕН РАБОТАТЬ С ВАШИМИ ПРОДУКТАМИ!

Поскольку мне не была известна эта ошибка, я должен был каждый раз после очередного изменения формата, в общей сложности около 50 раз включать и выключать Каталогизатора(Каталогизатор считывает форматы в память). Через несколько загрузок и выгрузок, система задыхалась от недостатка ресурсов(это, конечно отдельный вопрос) и её приходилось перезагружать. Модуль оказался в данном случае единственным "средством разработки"...

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

Относительно команды ref(mfn, ...)
Она есть и неплохо работает. Вот ссылка про ее работу:
[irbis.gpntb.ru]

А что за ошибка-то? Опишите ее подробнее! Я вроде не помню про ошибку, или не знал, или уже забыл.

Ответить, конечно, может только С.М., но я проясню один момент. Использование конструкции 'v991' - это было наше соглашение между программой и форматером. На это место програмно вставлялось явное значение поля 991, заданное при опросе. Но это уже можно не использовать, а пользоваться просто v991 или &unifor('Av991#1') в повторяющейся группе. Но в старых таблицах 'v991' осталось.

Я неоднократно отмечала, что таблица TABKOW применялась для первой версии задачи КО, затем была исключена из дистрибутива, но восстановлена по просьбе Пользователей, уже работавших с нею.
Все сложности формата объясняются именно теми ограниченными средствами, которые были в распоряжении писавших формат в те времена, что разъяснила программист Очагова Л.Н.
Так что a(v991^c) невозможно было применить (додуматься до этого мы бы, наверное, смогли), поскольку поле 991 в этом формате просто не существует.
А прием с применением конструкции
if p(v691) then if ref(mfn,(if p(v691) then if 'v991':v691^a or (not('v991':'^a')) then if 'v991':v691^b or (not('v991':'^b')) then if 'v991':v691^d or (not('v991':'^c')) then '1;'fi fi fi fi/)):'1'
позволял выявить наличие хотя бы одного из повторяющихся полей 691, удовлетворяющих заданным условиям. Согласна, ; можно было опустить, но позже мы стали применять для этой цели функцию RSUM, а там уже разделитель после 1 необходим.

Конструкция ref(mfn,..... не такая уж абсурдная, т.к. позволяет вытащить запись заново из БД, не учитывая возможных изменений, уже с ней сделанных (например, в autoin или в таблицах происходит временное добавление в запись поля 991)

> я должен был каждый раз после очередного изменения формата, в общей сложности около 50 раз включать и выключать Каталогизатора(Каталогизатор считывает форматы в память).

После изменения формата, достаточно в Word'е поменять на к.-н. другой формат и выбрать изменённый. Каталогизатор считывает в память только текущий формат.

В АРМе Каталогизатор производится кэширование форматов - для того чтобы заставить Каталогизатор обновить измененные форматы необходимо:
или на плоскости ПРОСМОТР дважды щелкнуть по окну ПОЛНОГО ОПИСАНИЯ
или на плоскости ВВОД дважды щелкнуть по окну подсказки (правый нижний угол).

О, тайна раскрыта! Спасибо.

ЗЫ. Хотя кажется об этой возможности уже упоминалось, только уже забыли все...

Дунаевская С.М. писал(а):

> Я неоднократно отмечала, что таблица TABKOW применялась для
> первой версии задачи КО
> Все сложности формата объясняются именно теми ограниченными
> средствами, которые были в распоряжении писавших формат в те
> времена, что разъяснила программист Очагова Л.Н.

Вы говорите о неудачных решениях, связанных с полем 991, в прошедшем времени, как о чём-то что уже никак не влияет на работу с новыми версиями. Не говоря уже о том, что я подробно разобрал, к каким ошибкам отбора приводят сегодня эти "решения"(см. пункт 7), я подчеркнул, что ПРОБЛЕМЫ С ПОЛЕМ 991 ДО СИХ ПОР ИМЕЮТ МЕСТО.

Вот работоспособный код отбора. v991^e - специализация.

if p(v691) and p(v991) then if s((if v691^c:v991^e or (not('v991':'^e')) then if v691^a=v991^a or (not('v991':'^a')) then if v691^b=v991^b or (not('v991':'^b')) then if v691^d=v991^c or (not('v991':'^c')) then '1' fi fi fi fi/))<>''

Теперь заменим (not('v991':'^e')) на а(v991^e). Так он должен выглядеть в оптимальном варианте.

if p(v691) and p(v991) then if s((if v691^c:v991^e or a(v991^e) then if v991^b=v691^b or a(v991^b) then if v991^c=v691^d or a(v991^c) then if v991^a=v691^a or a(v991^a) then '1' fi fi fi fi/))<>''

Что получается? Вместо трёх записей, содержащих выбранную специализацию, выводятся все записи с введёнными сведениями по книгообеспеченности. Вывод: a(v991^e) во всех случаях возвращает True, в то время, как подполе v991^e содержит верные значения. И это происходит не в версии 1998.1, а в версии 2004.2!

В написанных Вами форматах существенная ошибка: при сравнении значений повторяющихся полей 691 со значением неповторяющегося поля 991 нужно использовать не функцию v991^n, а функцию &unifor('Av991^n#1'). Об этом уже неоднократно писали в форуме (А.Карауш, М.Куделя)

Дунаевская С.М. писал(а):

> В написанных Вами форматах существенная ошибка: при сравнении
> значений повторяющихся полей 691 со значением неповторяющегося
> поля 991 нужно использовать не функцию v991^n, а функцию
> &unifor('Av991^n#1'). Об этом уже неоднократно писали в форуме
> (А.Карауш, М.Куделя)
>

Хотя А.С. Карауш и М.В.Куделя, ничего не писали мне об использованном мной формате, поскольку они просто его не видели :-), я признаю, что сделал грубую ошибку. Прошу прощения.