Ирбис-64, 2012.

Здравствуйте, возникла необходимость достаточно большой части фонда поменять шифр. Но если хоть один экземпляр выдан, то при изменении шифра в поле 903 - не везде меняется информация корректно, возникают проблемы и в АРМ Книговыдача и т.д. Как поменять шифр автоматически везде, даже при условии выданных экземплярах?

Спасибо.

New написал(а):
-------------------------------------------------------
> Ирбис-64, 2012.
>
> Здравствуйте, возникла необходимость достаточно
> большой части фонда поменять шифр. Но если хоть
> один экземпляр выдан, то при изменении шифра в
> поле 903 - не везде меняется информация корректно,
> возникают проблемы и в АРМ Книговыдача и т.д. Как
> поменять шифр автоматически везде, даже при
> условии выданных экземплярах?
>
> Спасибо.

"поменять шифр автоматически везде" можно глобальной корректировкой с отключенным ФЛК, но делать этого нельзя. Будет проблема с возвратом выданных экземпляров.

Здравствуйте, коллеги!
Можно ли увеличить длину поля 903? Начиная с 18-го (а у нас есть шифры 18-19 знаков) символы съедаются.

Где это у Вас происходит?

При сохранении записи в шифре (поле 903) отсекаются символы после 17-го знака (из поля 675). Соответственно, на карточке из тоже нет.

Это надо откорректировать файл autoin.gbl. Покажите этот файл

autoin.gbl

Возьмите измененный файл autoin.gbl.

Спасибо, Татьяна, все как надо!

У меня была необходимость поменять шифры во всех экземплярах (более 100шт) одного журнала. После того как я это сделал, они потеряли связь между собой. Причем если из любого экземпляра (выпуска) нажать на сводный, то возвращается к общей записи (простите, не знаю как это правильно назвать). А если из этой общей записи журнала нажать на кнопку "номера", то он их не находит. В чем может быть проблема? На что обратить внимание?

vergilgm написал(а):
-------------------------------------------------------
> У меня была необходимость поменять шифры во всех
> экземплярах (более 100шт) одного журнала. После
> того как я это сделал, они потеряли связь между
> собой. Причем если из любого экземпляра (выпуска)
> нажать на сводный, то возвращается к общей записи
> (простите, не знаю как это правильно назвать). А
> если из этой общей записи журнала нажать на кнопку
> "номера", то он их не находит. В чем может быть
> проблема? На что обратить внимание?


Покажите записи: сводную и номеров.

Может нужно актуализировать словарь после таких изменений? Если из самого номера журнала нажать на "сводный", то оно его находит, а в обратную сторону (по кнопке "номера") - не находит.

vergilgm написал(а):
-------------------------------------------------------
> Может нужно актуализировать словарь после таких
> изменений? Если из самого номера журнала нажать на
> "сводный", то оно его находит, а в обратную
> сторону (по кнопке "номера") - не находит.


Мне нужны сами записи, а не картинки

Извините, вот записи в формате .txt

vergilgm написал(а):
-------------------------------------------------------
> Извините, вот записи в формате .txt


Импортировала ваши записи 1.txt в тестовую БД IBIS через Каталогизатор. Оперативные режимы работают. См. Doc33.docx.
Cловарь заново не создавали? На других журналах, в которых не менялись шифры, оперативные режимы работают?

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

Все таки нужно попробовать словарь пересоздать?

UPD: Глупая ситуация по неопытности получилось. Действительно нужно было актуализировать словарь. Простите за такие глупые проблемы.



Редактировано 1 раз. Последний раз 05.09.2017 09:15 пользователем vergilgm.

Импортировали записи. Шифр в поле 903 создался автоматически вида "-xxxxxxx". На этот шифр завязаны некоторые процессы "интеграции" с другими системами университета. При работе с данной записью позже, шифр может меняться: так как в autoin'е есть условия удаления данного шифра.
Зачем это сделано? Не должен ли шифр быть неизменным?
Можно ли изменить нам autoin, чтобы шифр не менялся, если он заполнен?

И еще - создание его вида "-xxxxx" имеет довольно мало цифр, что может повлечь дублетный шифр. Я правильно понимаю, что можно поменять '-'&unifor('R') на '-'&unifor('R')&unifor('R'), например, чтобы уменьшить вероятность дублетов в таком случае?

С уважением, Лазарев Илья (Научная Библиотека ВятГУ)



Редактировано 2 раз. Последний раз 12.02.2018 22:46 пользователем iLq.

iLq написал(а):
-------------------------------------------------------
> Импортировали записи. Шифр в поле 903 создался
> автоматически вида "-xxxxxxx". На этот шифр
> завязаны некоторые процессы "интеграции" с другими
> системами университета. При работе с данной
> записью позже, шифр может меняться: так как в
> autoin'е есть условия удаления данного шифра.
> Зачем это сделано? Не должен ли шифр быть
> неизменным?

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


> Можно ли изменить нам autoin, чтобы шифр не
> менялся, если он заполнен?
Можно.

> И еще - создание его вида "-xxxxx" имеет довольно
> мало цифр, что может повлечь дублетный шифр. Я
> правильно понимаю, что можно поменять
> '-'&unifor('R') на '-'&unifor('R')&unifor('R'),
> например, чтобы уменьшить вероятность дублетов в
> таком случае?
Количество знаков случайного числа можно указать в &unifor('RNN')

Сорокина Лариса написал(а):
-------------------------------------------------------
> iLq написал(а):
> --------------------------------------------------
> -----
> > Импортировали записи. Шифр в поле 903 создался
> > автоматически вида "-xxxxxxx". На этот шифр
> > завязаны некоторые процессы "интеграции" с
> другими
> > системами университета. При работе с данной
> > записью позже, шифр может меняться: так как в
> > autoin'е есть условия удаления данного шифра.
> > Зачем это сделано? Не должен ли шифр быть
> > неизменным?
>
> Сделано с учетом библиотечных традиционных
> расстановок по классификационным индексам. Т.к.
> эти индексы могут быть введены позже, чем создан
> документ, то первоначально шифр строится, как
> случайное число (9-значное, начиная с версии
> 2014.1) с начальным дефисом.
>
>
> > Можно ли изменить нам autoin, чтобы шифр не
> > менялся, если он заполнен?
> Можно.
>
> > И еще - создание его вида "-xxxxx" имеет
> довольно
> > мало цифр, что может повлечь дублетный шифр. Я
> > правильно понимаю, что можно поменять
> > '-'&unifor('R') на '-'&unifor('R')&unifor('R'),
> > например, чтобы уменьшить вероятность дублетов
> в
> > таком случае?
> Количество знаков случайного числа можно указать в
> &unifor('RNN')

при указании больше 9 - не срабатывает. Может версия старовата. Если что, можно и скомбинировать несколько будет, не страшно.

С уважением, Лазарев Илья (Научная Библиотека ВятГУ)

Лариса Васильевна, вот не логичная получается ситуация с полем 903: поле должно быть уникальным и на него многие операции по связи записей между баз завязаны, при этом при изменении индексов ББК/УДК, когда новые индексы не входят в это поле, то в область просмотра зачем-то выводится шифр записи из этого поля. Получается, что если запись на книгу была создана, систематизирована, на внесенные в поля ББК/УДК поля сформировался шифр записи, а потом книга была выдана читателю, и перешифрована, то или придется наблюдать в области просмотра шифр со старым индексом, или прийдется и перешифровывать книгу, и пересоздавать новое поле 903, и редактировать данные о выданной литерауты, которые завязаны на этот шифр.

Но ведь правильнее было бы сделать это поле ни с чем не связанным с набором уникальных цифр/букв и оставить его только для связи записей. Очень хочется что бы в будуших версиях произошла "отвязка" поля 903 от индексов.

Вот можно же сделать его формирования например вот так:

&uf('r5')'-'&uf('r5')'-'&uf('r5')'-'&uf('r5')'-'&uf('r5')

работает почти моментально, а на выходе получаем вот такое:

89566-05217-95261-97544-59712

Gena написал(а):
-------------------------------------------------------
> Лариса Васильевна, вот не логичная получается
> ситуация с полем 903: поле должно быть уникальным
> и на него многие операции по связи записей между
> баз завязаны, при этом при изменении индексов
> ББК/УДК, когда новые индексы не входят в это поле,
> то в область просмотра зачем-то выводится шифр
> записи из этого поля. Получается, что если запись
> на книгу была создана, систематизирована, на
> внесенные в поля ББК/УДК поля сформировался шифр
> записи, а потом книга была выдана читателю, и
> перешифрована, то или придется наблюдать в области
> просмотра шифр со старым индексом, или прийдется и
> перешифровывать книгу, и пересоздавать новое поле
> 903, и редактировать данные о выданной литерауты,
> которые завязаны на этот шифр.
>
> Но ведь правильнее было бы сделать это поле ни с
> чем не связанным с набором уникальных цифр/букв и
> оставить его только для связи записей. Очень
> хочется что бы в будуших версиях произошла
> "отвязка" поля 903 от индексов.
>
> Вот можно же сделать его формирования например вот
> так:
>
> &uf('r5')'-'&uf('r5')'-'&uf('r5')'-'&uf('r5')'-'&u
> f('r5')
>
> работает почти моментально, а на выходе получаем
> вот такое:
>
> 89566-05217-95261-97544-59712

Для пущей уникальности я бы добавил дату-время вначале:
&uf('3'),'-',&uf('+98:-',&uf('39')),'-',&uf('r5'),'-',&uf('r5'),'-',&uf('r5'),'-',&uf('r5')

20180220-22-56-03-05217-95261-97544-59712

С уважением, Лазарев Илья (Научная Библиотека ВятГУ)

Тогда еще должны какие то цифры у вас базу отражать, а то будут дублеты, например, кто-то вводит статьи в БД ЭК, а кто-то в это время - книги в cMPL. Потом при переносе в БД ЭК проблемы будут. Пишу это т.к. у нас и сейчас бывает, что шифры из cMPL совпадают с шифрами статей. Лечим это как раз добавлением авторского знака и формированием 903 с авторским знаком

roit написал(а):
-------------------------------------------------------
> Тогда еще должны какие то цифры у вас базу
> отражать, а то будут дублеты, например, кто-то
> вводит статьи в БД ЭК, а кто-то в это время -
> книги в cMPL. Потом при переносе в БД ЭК проблемы
> будут. Пишу это т.к. у нас и сейчас бывает, что
> шифры из cMPL совпадают с шифрами статей. Лечим
> это как раз добавлением авторского знака и
> формированием 903 с авторским знаком

Время + столько различных случайных чисел навряд ли совпадут, но почему бы и не добавить базу! Только это надо будет в каждом autoin добавить вручную. Или можно через uf? не нашел сходу такой функции.

С уважением, Лазарев Илья (Научная Библиотека ВятГУ)

iLq написал(а):
-------------------------------------------------------
> Время + столько различных случайных чисел навряд
> ли совпадут, но почему бы и не добавить базу!
> Только это надо будет в каждом autoin добавить
> вручную. Или можно через uf? не нашел сходу такой
> функции.

&unifor('+D')

Да не нужно в это поле вообще никаких осмысленных данных вносить. Оно по определению должно быть уникальным, не пересекающимся и обезличенным. Но пол беды, что в него сейчас пишутся авторский знаки и шифр. Меня больше всего смущает то, что при несовпадении шифра в 621/675 полях и 903 поле, это поле начинает выводиться в область полного описания и даже на каталожную карточку! Опять так вернусь к вопросу, что если по какой-то причине у меня была выдана книга, а потом потребовалось ее перешифровать - дать другой индекс, то я обязан сделать следующие действия:

1. Ввести в запись новые индексы ББК/УДК
2. Найти всех читателей, у которых сейчас на руках есть экземпляры этой книги
3. Удалить в книге старый шифр и сохранить запись, что бы в ней сформировался новый шифр
4. В каждой записи читателя, у которого на руках есть экземпляры этой книги, изменить шифр книги со старого значения на новое.

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

Где логика?!

так как избавиться от 20-значного шифра в полном описании и убрать с печати на каталожной карточки?!



Редактировано 1 раз. Последний раз 26.02.2018 09:48 пользователем FriskySnooP.

Gena написал(а):
-------------------------------------------------------
> Да не нужно в это поле вообще никаких осмысленных
> данных вносить. Оно по определению должно быть
> уникальным, не пересекающимся и обезличенным. Но
> пол беды, что в него сейчас пишутся авторский
> знаки и шифр. Меня больше всего смущает то, что
> при несовпадении шифра в 621/675 полях и 903 поле,
> это поле начинает выводиться в область полного
> описания и даже на каталожную карточку!

В левом верхнем углу выводится расстановочной шифр.

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

По каким причинам и как часто требуется изменение индексов?

Лариса Васильевна, в левом верхнем углу может выводиться много чего. Сейчас там очень не простой алгоритм того, что там отображается: или первый индекс ББК/УДК, или систематический шифр, или раздел знаний, или расстановочный шифр (приоритет выше остальных), или в том случае, когда в ни ББК, ни УДК, ни раздел знаний не входят в 903 поле, то выводится именно само 903 поле (самый высокий приоритет). Так же есть куча заморочек по поводу хитрых видов изданий


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

Поддерживаю, что шифр документа в базе должен быть уникальным, один раз создаваемым системой и не доступным для редактирования пользователем.
Например, при создании записи при книговыдаче, запись формируется с урезанным количеством полей, по которым формируется поле 903.
Затем книга возвращается, заполняются все поля, и перешифровывается (по крайней мере наши каталогизаторы делают так, объясняя, что тот шифр был неполным). Соответственно в статистике книговыдачи эта книга уже не бьется.
Мы пока не нашли решения данной ситуации.

Ответ на вопрос "По каким причинам и как часто требуется изменение индексов?" - это совершенно обычная процедура в библиотеке. У нас, например, используются индексы ББК в качестве полочных с 1984 года, до того были другие индексы, тоже систематические. Полочный индекс у нас в 906 поле. В 621 индексы ББК более подробные.
Самый простой пример изменения индексов - ошиблись при первоначальном присвоении индекса. Кстати, и с авторским знаком тоже бывают ошибки.
Кроме того, например, мы может возникнуть необходимосььб перешифровать старые индексы (те самые до 1984) на ББК и переставить фонд. Или вышли новые таблицы ББК и мы может быть захотим перешифровать и переставить тоже фонд по ним. Т.к. эта процедура трудоемкая, то как правило, мы этим не занимаемся. А с введением в строй электронной книговыдачи и вышеописанных коллегами проблем совсем уж получается невозможная задача.
Но вот с ошибками в шифрах это бывает. И как раз всплывает при книговыдаче. Хорошо, когда успеваем поймать до того как выдадим читателям. Но чаще именно приходится делать мне глобальные корректировки в базе и записи читателя поправляя такие ошибки.