ИРБИС64 Версия 2014.1(D5)
Для построения отчета по книговыдаче по конкретным библиотекарям(пользователям) требуется "Ответственное лицо" не менять при продлении и возврате книг.
Подскажите, пожалуйста, что для этого можно предпринять в рамках рабочей версии.

Дашкова Елена
МУК ЦСДБ г.Ярославль

Задача действительно актуальная, но предложить решение не так-то просто, поскольку в Системе не предусмотрено сохранение информации обо всех ответственных лицах за все этапы книговыдачи в актуальной версии записи читателя. Фиксируется лицо, последним выполнявшее какие-либо действия с выданными экземплярами.

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

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

НО! Т.к. при реорганизации БД все неактуальные (предыдущие) копии записей удаляются форма будет актуальна на период между реорганизациями БД.
Т.е. если книговыдача интенсивная и реорганизация БД проводится каждый месяц, то форма сможет применяться только за месяц и строиться должна будет до проведения реорганизации БД читателей.

Может есть еще варианты?

При работе с нашей версией базы данных читателей при книговыдаче, продлении, возврате не создается новой версии записи, реорганизация не выполняется, корректируется текущая запись и все. Хотелось бы решение влияющее на корректировку записи, скорректировать файл autoin.gbl(если он отрабатывает при корректировке) или какой-то файл fst, если можно.

ДашковаЕлена написал(а):
-------------------------------------------------------
> При работе с нашей версией базы данных читателей
> при книговыдаче, продлении, возврате не создается
> новой версии записи, реорганизация не выполняется,
> корректируется текущая запись и все.

Похоже, Вы путаете понятие версии записи и повторения 40-го поля.
Может не создаваться дополнительных повторений 40-го поля, но предыдущие копии самой записи читателя безусловно создаются. Посмотрите соответствующую кнопочку в интерфейсе АРМ Каталогизатор.

> Хотелось бы решение влияющее на корректировку записи,
> скорректировать файл autoin.gbl(если он
> отрабатывает при корректировке) или какой-то файл
> fst, если можно.

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

Можно в принципе переносить данные в какое-либо свободное поле, например 401 и по нему строить отчеты.

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

И autoin_light.gbl (именно он используется в АРМ Книговыдача) и fst скорректировать можно, только стоит ли? Для чего изобретать новый велосипед?

В версии 2016.1 появилась технология работы с архивированием данных об обслуживании читателей. Стоит рассмотреть возможности, предлагаемой разработчиками технологии, т.к. в архивных записях вполне можно вести всю историю и строить с помощью этой БД нужные отчеты.



Редактировано 1 раз. Последний раз 12.05.2017 08:25 пользователем А. Роман.

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



Редактировано 1 раз. Последний раз 12.05.2017 10:21 пользователем ДашковаЕлена.

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

ДашковаЕлена написал(а):
-------------------------------------------------------
> В АРМ Каталогизатор жму кнопочку "предыдущие копии
> записи" и выдает сообщение "Текущая запись не
> имеет предыдущих копий". Возможно у нас установлен
> какой-то параметр, благодаря которому не создаются
> предыдущие копии записи.

Такого параметра на сколько мне известно нет. Проверьте на других записях. Или выполните какую-либо процедуру со своей записью (Вы ведь наверняка тоже в БД читателей есть) после чего посмотрите на результат.

> Не предлагаю новые
> повторения 40 поля, просто формировать его по
> другому,сохранив подполе "выполнивший книговыдачу"
> и возможно расширив количество подполей в нем,
> например добавить подполе "последний изменивший".
> Наша версия - ИРБИС64 Версия 2014.1(D5)

Категорически не стоит этого делать, т.к. с полем "Ответственное лицо" связано много технологий, форматов и выходных форм. Именно это поле дает информацию о последнем сотруднике, выполнявшем действия с "электронным формуляром" читателя.

Опять же как поступать с теми, кто выполняет продление по 2-3 раза и более?

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


Очень жаль, что при этом не ставится целью повышение эффективности труда за счет модернизации средств производства...

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



Редактировано 1 раз. Последний раз 12.05.2017 10:19 пользователем ДашковаЕлена.

Я не являюсь разработчиком, но скажу по собственному опыту - свои ходы разработчики безусловно знают, а вот ходы пользователей - конечно нет.

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



Редактировано 1 раз. Последний раз 12.05.2017 10:18 пользователем ДашковаЕлена.

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

Спасибо за предложения по решению моей проблемы.

Елена, предыдущие версии записей создаются в любом случае. Этот параметр определяет только актуализацию словарей БД и не сказывается на предыдущих копиях записей. Они создаются как при значении 0 так и при 1.

Не совсем понял о каких регламентных операциях речь? Об актуализации словарей БД?

Для актуализации записей в БД RDR и БД ЭК при выборе такого режима достаточно создать пакетное задание и в планировщике задач стартовать каждые 3-5 минут АРМ Администратор с этим заданием.

На счет скорости работы - однозначно в отсутствии автоактуализации АРМ Книговыдача работает быстрее.

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

ДашковаЕлена написал(а):
-------------------------------------------------------
> Про скорость работы имела в виду наличие копий, а
> не актуализацию записи.
> Вероятно при отсутствии копий, после реорганизации
> скорость работы возрастет.

Однозначно возрастет, т.к. количество копий определяет размер мастер-файла БД RDR.MST и в случае интенсивной книговыдачи, а также при загрузке файлов фотографий в поле 953 данный файл может существенно разрастись.


> Надо выяснить насколько
> копии нужны библиотекарям и выполнить
> реорганизацию, мне они пока не требовались.

В обычной работе копии не требуются, но могут понадобиться для выяснения истории работы с тем или иным читателем или например для возврата случайно списанных с читателя экземпляров (бывает, когда сотрудники пункта выдачи осуществляют возврат по кнопочке, торопятся и не читают предупреждающее сообщение).

На всякий случай стоит держать копии (основной пятерки) файлов БД для того, чтобы иметь возможность оперативно восстановить какую-то отдельную информацию. (файлы можно скопировать в отдельную БД, например RDR2, (переименовав файлы в RDR2.*) и отработать на этой БД следственные мероприятия при помощи того же АРМ Каталогизатор.

Добрый день, Роман.
Свою проблему по сохранению ответственного за книговыдачу решила следующим образом - добавил новое подполе 40^z в записи о читателе.
Добавлено в autoin_light.gbl
....
IF
if p(v40^i) then '1' else '0' fi
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
REP
40^i
F
(if &uf('Av40^F')='******' and &uf('Av40^Z') ='' then &uf('Av40^i'),'^Z',&uf('Av40^i') else &uf('Av40^i') fi/)
XXXXXXXXXXXXXXXXXXX
FI
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXX
...

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

По поводу копий записей в БД - в нашем учреждении этой возможностью никто не пользуется. Для восстановления истории можно воспользоваться ежедневным бэкапом БД, который мы сами делаем, пока ни разу не требовалось. Может это только у нас, но наличие копий представляется анахронизмом. БД читателей с 1Гб уменьшилась до 30Мб после реорганизации, данные росли с начала 2017 года.

С уважением,
Дашкова Елена

Предложенное в предыдущем письме решение находится на тестировании. Хотелось бы получить от участников форума помощь, замечания, указания на подводные камни, предложения, например, по названию подполя, выбрано 40^Z (наугад, без царя в голове).