Сначала был Ирбис. И все было хорошо :-). Затем каталог начал подбираться к 80 тысячам. Наполняли каталог несколько каталогизаторов. Стали появляться в поиске термины, начинающиеся с пробелов. Оказалось в полях есть лишние пробелы. Возник вопрос: а на сколько много ошибок в нашем каталоге? Начали смотреть, проверять. Оказалось – много. И не только ошибок, связанных с лишними пробелами. Чего только нет! То кодированные данные не там или вместо кода написано нечто словесное, то от номера журнала нельзя выйти на источник (а попробуй-ка отсмотреть все номера или статьи… ), то встретятся два журнала с одинаковыми шифрами, то дату напишут как нормальные люди «22.01.83», а не как операторы «Ирбиса» «19830122». Где-то вообще цифру пропустят (книга 199 года… Сначала удивился – надо же какой раритет!). В общем, надо было что-то делать…

В итоге, я написал программу, которая проверяет БД на корректность, попутно делая в ней мелкие исправления. (документацию можно посмотреть тут: [library.omsu.ru]). Запускается ночью, выдает примерно такой отчет о работе:

000043: Ошибочный код вида периодического издания (240 в год)
000043: Не указано издательство (издающая организация)
000074: Ошибочный код вида периодического издания (6 раз в неделю)
000681: Откорректировано Выходные данные/Город 1: было (М. ) стало (М.)
003494: Неизвестный код языка параллельного заглавия (английский)

Для Ирбиса на данный момент реализована проверка документов с 920=J (описание журнала), 920=NJ (Описание номера журнала). Готовится к запуску v920=ASP. Попутно развиваем возможности проверок и автоматических исправлений.

Вопрос: Это кому-нибудь кроме нас надо? :-)

Программа интересная, только я так и не понял языка формальных проверок.
Все это на pft написано, что потом говорит в строке отчета, что в записи что-то некорректно?

Огромная просьба: прислать и дать посмотреть данную программу или выложить.

Может быть предложить Вам формализовать проверки в виде таблиц соответствия, написанных на pft языке.

Такие вещи можно также делать на конверторе fst. В случае использования конвертора можно писать на естественном языке и использовать все uniforы и русские буквы, что гарантирует совместимость.

Но я еще не встречал таблиц формализации правильности записей. Это сложные таблицы, пусть даже при простой проверке записей на корректность.
Может Вы остановитесь именно на написании fst конвертора, который будет в подобном формате писать отчет, что у Вам приведен, выполняясь из АРМ Администратор в автоматическом режиме?

Написано это все НЕ на pft. pft используются при выводе собщения об ошибке. Сам исходный код атомов проверки зашит в exe файл (такие как CHECK ISSPACESONLY) У приведенной в примере функции 1 параметр - сообщение об ошибке. Если перед этим установить еще и переменную AUTOCORRECT в YES, то поле целиком состоящее из пробелов будет удалено из mst-файла.
Очень жалею, что нет интерфейса к format32.dll (Уважаемые разработчики - может поделитесь? :-)) - иначе можно было бы использовать и команды &unifor, что дало бы возможность полностью поддерживать язык форматирования Ирбис. Соответственно и возможность решить проблему с автоматическим пересозданием индексов.

Пример проверки (в скобках - номера строк, в оригинале не указываются. :-)):

; Год издания

(1) CHECKLIST "v934"
(2) {
(3) SET AUTOCORRECT YES "mfn, ': Откорректирован год издания: было ($PrevValue) стало ($CorrectedValue)'/"
(4) CHECK ISSPACESONLY ""
(5) CHECK PRESENTSPACESLEFTANDRIGHT ""
(6) SET AUTOCORRECT NO
(7) SET BREAKONCHECK YES
(8) CHECK ISEMPTY "mfn, ': Не указан год издания'/"
(9) CHECK YEARNOTCORRECT "mfn, ': Некорректный год издания ('v934')'/"
(10) }

(1) Проверяем поле 934.
(2) Разрешаем корректировку, при корректировке используем указанный темплейт.
(4) Проверяем, не состоит ли поле целиком из пробелов. Если состоит - ничего не выводим в лог - поизойдет корректура, информация о которой будет выведена в лог (в соответствии с (2))
(5) Проверяем наличие пробелов слева и справа. Аналогично (4)
(6) Запрещаем автокорректировку.
(7) указываем программе, что при срабатывании 1-й же проверки необходимо прекратить проверку поля. (т.е., в данном случае, если поле пусто, то проверка на корректность написания года проводиться не будет)
(8) Проверяем не пусто ли наше поле? Если да -выводим соответствующее сообщение в лог.
(9) Если все же не пусто, проверяем на корректность заполнение даты.
(10) Заканчиваем обработку поля 934.


От fst отказался в силу слишком больших затрат на ее написание. И, что не менеее важно, на изменение. Да и использовать ее прямиком из Ирбиса - необходимо находиться на рабочем месте. Плюс, после использования необходимо выполнение дополнительных действий. А тут все автономно, ночью. Никто ничего не забудет сделать, времени не отнимает. Утром остается только убедиться что все хорошо. :-)

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

Так ведь они и так вынесены (см. файлы Checks\*.chk)! Изменились стандарты - пожалуйста - подправляем текстовый файл проверок и всё...
В том то и смысл программы, что бы можно было достаточно оперативно делать проверку БД. Задача программиста лишь дать как можно более удобный инструмент для работы технолога.

PS: Видимо, не умею я писать документацию... :-)

Так мне только документация и попалась. Программы-то я не видел. Я же тоже не читатель, я - "запускатель", или писатель, однако.

Действительно, было бы интересно позапускать, а то читать документацию на программу, не имея оной перед глазами, это как-то не в моих правилах :). Может есть линка на сам ехе где-нить в дебрях интернета? Неужели не интересно услышать мнение коллег по разуму :).

Илья, пожалуйста, выложите программу куда-нибудь. Хочеться проверить, как хорошо она справляется с ошибками

Выложил и саму программу тут:
[library.omsu.ru]

2Карауш А. С.: Отсылал Вам программу на E-Mail еще вчера. Пришло сообщение от mail-сервера:
Connection timed out with mibs.tsu.ru.
Warning: message still undelivered after 4 hours
Will keep trying until message is 2 days old

А у меня адрес уже с хвостом library.tomsk.ru

Возникла у наших каталогизаторов задача. Есть БД с "грязными" описаниями, они частями обрабатывают эту БД и отредактированные записи складывают в "чистую" БД. База "грязных" записей у нас довольно большая - порядка 15 тысяч, записи редактировались НЕ по порядку. Сама по себе технология ужасна, но... Начали путаться, какие записи переброшены, какие нет. В итоге решили так: Они ведут у себя текстовый файл, где перечислены все записи, которые были переброшены и которые надо перебросить. Файл примерно такого содержания (промежутки разделяются либо запятой, либо новой строкой):
1-8700
8720-8733
8800-8802
8004
8009
8011-8013
Программа запоминает какие записи уже были переброшены, какие еще нет. Соответственно, когда каталогизаторы добавляют в этот файл строку
8010
Программа перебрасывает эту (и только эту) запись в "чистый" каталог, и перезаписывает исходный файл вот таким:
1-8700
8720-8733
8800-8802
8004
8009-8013
(т.е. сам объединяет все промежутки)
У каталогизаторов есть картина какие записи отработаны и переброшены, какие еще нет. И у нас (автоматизаторов) проблем поубавилось.
[library.omsu.ru]
PS. Если у Вас возникнут какие-нибудь предложения по расширению функциональности программы - пишите на library@omsu.omskreg.ru С радостью отвечу. Если что-то не будет получаться - то же пишите, постараюсь помочь.

Средствами ИРБИСа можно было бы ввести специальный код этапа работы "завершение", по нему (с датой) передавать записи в "чистую" БД, а в записи "грязной" выводить в формате просмотра по наличию этого кода сообщение типа "Обработка завершена".

Пришлось бы заводить два кода: 1-это "запись готова к передаче", 2 - это "запись передана" (доступ на запись к выходным каталогам имеет только "корректор"). Появятся проблемы при передаче в две и более БД одновременно (например, содержащие записи, сгруппированые по какому-либо признаку), человеческий фактор: в одну БД запись перебросили, в другую забыли. Плюс к этому, возникнут проблемы с поддержкой: каждая новая версия файлов просмотра от раработчика влечет за собой их корректировку.
В этом решении "корректор" просто имеет перед собой текстовый файлик, где указано какие записи переброшены, какие нет. Вся переброска производится ночью в автоматическом режиме. Настраивается все один раз.
Конечно, есть и свои минусы. Самый нехороший - это привязка к mfn в "грязной" базе.