У нас используется RFID и техника так настроена, что в 30 поле должна быть RFID-метка читательского билета. Т.е. когда мы заменяем билет, то мы вынуждены заново считывать в 30 поле уже другую метку. Все бы не страшно, но при использовании RDR_ARH получается, что надо корректировать и эту базу: найти в ней все записи, где в 30 поле старое значение и заменить на новое. Сейчас это делается так: сотрудники абонемента записывают старое и новое значение и передают мне, я глобальными корректировками подправляю RDR_ARH.
Читатели теряют билет часто и в течении года, и студенты заканчивая бакалавриат часто тоже куда-то теряют билет (должны сдавать), а потом поступают на магистратуру нужно выдавать новый. Получается, что при очень даже стандартной на абонементе ситуации, сотрудники сами не могут выполнить свою работу.
А уж с переходом на кампусные карты это будет еще более массовое явление. Это же банковская карта, они бессрочными не бывают.
Очень просим уважаемых разработчиков придумать какое-то решение, например, некую кнопку в Книговыдаче или хотя бы что-то в Каталогизаторе для замены 30 поля с тем, чтобы оно менялось и в RDR_ARH. И чтобы это было решение доступное именно обычному библиотекарю, у которого нет доступа к глобальным корректировкам.



Редактировано 2 раз. Последний раз 25.11.2019 12:36 пользователем roit.

Здравствуйте, тоже интересует эта проблема.

По хорошему, в текущей ситуации нужно добавить сценарий глобальной корректировки в файл автоввода для автоматической смены идентификатора в БД RDR_ARH (на основе проверки предыдущей копии записи читателя).

Что-то вроде:

IF
if v30<>&uf('41,v30') then '1' else fi
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
CORREC
'RDR_ARH'
V30
'RI='if v30<>&uf('41,v30') then &uf('41,v30') else fi

REP
30
1
V1001
XXXXXXXXXXXXXXXXXXX
DEL
1001
*
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
END
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
FI
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX

Нам бы очень хотелось чтобы это или другое решение сделали разработчики т.к. это явно не уникальная наша ситуация, когда надо поменять 30 поле в RDR тем, кто пользуется RDR_ARH. Очень просим!



Редактировано 1 раз. Последний раз 17.01.2020 17:18 пользователем roit.

Если делать по уму, то в поле 30 должен быть строго неизменяемый идентификатор читателя, а номер карточки RFID - в любом другом отдельном поле.
Тогда вышеописанная ситуация не будет столь критична при создании статистики.

Может быть если делать с самого начала 30 поле и может быть построено так. Но есть реальная не теоретическая проблема.
На 30 поле уже настроена вся техника и все программы как на самой технике, так и оба сип2, которые на сегодняшний день официально распространяет ИРБИС. Мы с 2013 года так работаем. И не только мы так работаем.
Именно поэтому и есть просьба к разработчикам что-то придумать для архивной базы. Тем более, что похоже, судя по варианту Р. Альшанского, такой выход может быть найден без революции с 30 полем.



Редактировано 2 раз. Последний раз 20.01.2020 22:02 пользователем roit.

roit написал(а):
-------------------------------------------------------
> Может быть если делать с самого начала 30 поле и
> может быть построено так. Но есть реальная не
> теоретическая проблема.
> На 30 поле уже настроена вся техника и все
> программы как на самой технике, так и оба сип2,
> которые на сегодняшний день официально
> распространяет ИРБИС. Мы с 2013 года так работаем.
> И не только мы так работаем.
> Именно поэтому и есть просьба к разработчикам
> что-то придумать для архивной базы. Тем более, что
> похоже, судя по варианту Р. Альшанского, такой
> выход может быть найден без революции с 30 полем.

Это что, в RFID софте "намертво" вшиты номера полей без возможности кастомизации?
С точки зрения нормальной разработки и сопровождения ПО и БД - это бредовая и совершенно недопустимая ситуация.
Ну да за последние ~20 лет я в ИРБИСе много чего нелогичного насмотрелся...

Есть в записи ИРБИСа поле 2147483647, хранящее некое подобие _id записи, значение вида "{3D3764B2-225A-47D8-96F4-F7408E925E72}" (своеобразная калька с серьёзных СУБД), это значение, уникальное для каждой записи в БД и неизменяемое в течение жизненного цикла записи. Оно используется в полнотекстовой подсистеме ИРБИС64+ для связи записи описания с соответствующими записями в полнотекстовой базе. В принципе, можно было бы аналогичным образом организовать связь записей в разных БД ( в том числе и RDR с RDR_ARCH), записывая в дочернюю запись значение поля 2147483647 материнской записи. Но напрямую средствами языка формата это поле, похоже, никак не выцепить (в языке формата зачем-то ограничение на длину номера поля), только сторонней реализацией на каком-нибудь ЯП.

Хотелось бы услышать от разработчиков про возможные перспективы его использования.

update:
детальное вчитывание в ibis.fst дало &uf('+*') - команда для доступа к содержимому данного поля. Отсюда можно двигаться дальше.



Редактировано 1 раз. Последний раз 21.01.2020 09:59 пользователем Игорь.

Для меня все эти рассуждения сложные. Именно поэтому я, и не только я, и обращаюсь к разработчикам за готовым инструментом, который позволил бы обычному библиотекарю отдела обслуживания меняя билет менять 30 поле не только в RDR, но и в RDR_ARH. Поэтому очень хотелось бы не рассуждений продвинутых пользователей на тему что такое хорошо и что такое плохо и что можно было бы самим дописать. Мне уже давно ясно, что продвинутые могут практически всё сделать. Но нам нужен именно инструмент готовый, в дистрибутивной версии ирбиса. В конце концов вариантов, когда в 30 поле номер билета тот или иной и его надо поменять без ущерба для архива полно в разных библиотеках по разным причинам.

Все верно, вы все правы. но когда случатся перемены - зависит сейчас от разработчиков и руководства Ассоциации ЭБНИТ. Что касается активности пользователей - то ее уже более чем достаточно для принятия и реализации ряда важных решений!

С 17 по 19 февраля в Санкт-Петербурге намечено проведение форума "школа ИРБИС" и "школа НАББ" (Яков Леонидович Шрайберг лично проводил на этот счет переговоры с уважаемыми коллегами из СПбГУ, СПбГИК, ЦГПБ им. Маяковского).
До этого в Москве должно состояться совещание научно-консультативного совета Ассоциации ЭБНИТ.
Хорошие новости безусловно будут.