Подскажите, пожалуйста, какую именно проверку надо выбрать и с какими параметрами, если:

- в БД IBIS появилось очень много экземпляров, у которых стоит статус "1", а на самом деле эти книги лежат на полке и по БД RDR их нет в выданной и не сданной литературе.

Я думаю что это должна быть такая проверка:
Контроль системы Книговыдачи -> БД Каталога -> корректировать БД каталога

Но так как нет времени на тестирование данной операции, то может кто уже пробовал применять к своей БД такую проверку?
я так понимаю в результате будет заменяться только статус экземпляра? никакие другие данные не будут меняться?
Помогите, пожалуйста, так как нужно сегодня после работы эту проверку запустить так как невозможно выдавать книги, так как у почти каждой второй стоит статус 1 а должен быть 0

ssa_admin написал(а):
-------------------------------------------------------
> Подскажите, пожалуйста, какую именно проверку надо
> выбрать и с какими параметрами, если:
>
> - в БД IBIS появилось очень много экземпляров, у
> которых стоит статус "1", а на самом деле эти
> книги лежат на полке и по БД RDR их нет в выданной
> и не сданной литературе.
>
> Я думаю что это должна быть такая проверка:
> Контроль системы Книговыдачи -> БД Каталога ->
> корректировать БД каталога
>
Именно так. Только оОБЯЗАТЕЛЬНО предварительно выполните СОХРАНЕНИЕ ФАЙЛА ДОКУМЕНТОВ в АРМе Администратор для этой БД



> Но так как нет времени на тестирование данной
> операции, то может кто уже пробовал применять к
> своей БД такую проверку?
> я так понимаю в результате будет заменяться только
> статус экземпляра? никакие другие данные не будут
> меняться?
> Помогите, пожалуйста, так как нужно сегодня после
> работы эту проверку запустить так как невозможно
> выдавать книги, так как у почти каждой второй
> стоит статус 1 а должен быть 0

Почему-то не получилось провести указанную выше проверку, т.е. проверка была запущена в 8 вечера и сегодня в 8 утра на полосе хода проверки всего две "палочки", поэтому пришлось остановить, т.к. в процессе проверки процессор сервера был загружен на 100%, что не давало бы нормально работать библиотекарям на своих рабочих местах.
Скажите, пожалуйста, сколько примерно времени должно быть затрачено на такую проверку, если в базе чуть больше 98 тыс. записей?

p.s. сегодня будет "жаркий" денечек, сотрудники абонементов меня "съедят"

начал проверять порциями по 100 mfn, вроде бы получается
Вопрос: можно ли эту проверку делать во время работы отделов книговыдачи? не будет ли плохих последствий?

и еще что означает сообщение "Несогласованные записи"?

Несогласованные записи, когда читателя нет, а в книге стоит статус "1"

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

Скажите, пожалуйста, а возможна ли ситуация, когда проверка "Контроль системы Книговыдачи -> БД Каталога -> корректировать БД каталога" показала результат, что не найдено ошибок в определенном диапазоне MFN, а на практике уже было с десяток записей (из этого диапазона MFN) у которых в электронном каталоге стоит статус "1", а на самом деле в БД RDR нет таких книг в статусе "на руках"?

Да, посмотрел на последнюю такую запись, и оказалось такое,
после проверки был выдан результат проверки:

IBIS 93084 340/П 68-547330 E0040100302F1AAB 3477 Несогласованные записи

Просмотрев запись в RDR с номером 3477 увидел, что указанная книга была сдана, но в электронном каталоге статус стоял "1" и после проверки остался таким же.

Может кто-нибудь как-то прокомментировать данную ситуацию?

очередной "факт" после проверки

книга имела статус "1", хотя по RDR ни у кого на руках не числилась,
по протоколам проверки такого mfn вообще нет, т.е. соответственно, ошибок в этой записи не должно быть.

Это неправильно. А в чем вы работаете?

Работаю в Ирбис 64 2009.1 (D1,D2)

Помогите, пожалуйста, разобраться с этими "Несогласованными записями".
Не понятно, почему именно такое сообщение появляется и что оно все таки должно означать.
После проверки всей БД в протоколах очень много этих "Несогласованных записей". Выборочная проверка таких записей в БД показывает разное:
1. книга в RDR на руках и в IBIS статус "1"
2. книга в RDR сдана, но в IBIS статус "1"

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

Уважаемые разработчики, можете обратить внимание на данную проблему?

Уважаемые коллеги, при контроле системы книговыдачи мы тоже встретились с сообщением "Несогласованные записи".
Простой пример (для IBIS), позволяющий сгенерировать данное сообщение в протоколе.
1. Выдать конкретный экземпляр читателю, затем оформить возврат, а затем снова выдать тому же читателю.
Тогда в поле 40 записи читателя будет более чем одно повторение с одинаковыми значениями подполей (именем базы данных ЭК, шифром, инвентарным номером).
2. При контроле системы книговыдачи с параметрами "БД Каталога", только для MFN выданного на шаге 1 документа глобальная корректировка DATAI\IBIS\chkcat.gbl сформирует два повторения служебного поля 2333. Первое повторение - со значением "2", второе - со значением "3". Chkcat.gbl (на данный момент) устроена таким образом, что при наличии в служебном поле 2333 значения "2" выставляется флаг "NOK". Последующие строки кода корректировки по флагу "NOK" формируют сообщение "Несогласованные записи".

Действительно в пакетном задании проверки по БД каталога, когда экземпляр со статусом 1 ищется у читателя, то достаточно факта, что есть факт сдачи. Надо проверять по последнему состояни этого экземпляра в записи читателя. Эадание будет исправлено в ближайшем обновлении.

Людмила Николаевна, скажите, пожалуйста, а не должна ли осуществляться ещё и проверка на количество повторений с кодом "3" в поле 2333? Таких повторений должно быть не более чем 1 (0 -
несогласованные записи, 1 - согласованные записи)?

Так экземпляр у одного читателя может 10 раз выдаваться и возвращаться. Поэтому проверка на =1 не годится. Даже не годится проверка по последнему, т.к. последним повторением поля 40 м.б. эта же книга, но другой инвентарь, тогда v2333=1 - моя логика не сработает.

ochagova написал(а):
-------------------------------------------------------
> Действительно в пакетном задании проверки по БД
> каталога, когда экземпляр со статусом 1 ищется у
> читателя, то достаточно факта, что есть факт
> сдачи. Надо проверять по последнему состояни этого
> экземпляра в записи читателя. Эадание будет
> исправлено в ближайшем обновлении.

скажите, пожалуйста, это исправление вошло в 4 обновление для Ирбис 64 ?

Это исправление вошло в D3, файл chkrdr.gbl

Добрый день.
При очередном контроле книговыдачи в протокол проверки БД Каталога попали сообщения "Несоответствует кол-во выданных со статусом U и кол-во по БД RDR".
Попробовали дополнить chkcat.gbl от 31.03.2010 г., так чтобы количество выданных в БД ЭК устанавливалось по БД RDR (если значение по БД RDR не превышает количества экземпляров со статусом U в БД ЭК).
Формируем сообщения:
- Нет данных о выданных со статусом U по БД RDR (в дополнение к Несоответствует кол-во выданных со статусом U и кол-во по БД RDR);
- Kол-во выданных со статусом U по БД RDR больше зарегистрированных;
- Установлено число выданных экз-ров для статуса U по БД RDR.
Прикрепляем дополненную версию chkcat.gbl во вложении.

Проверила ваше задание, согласна с доработкой. Включим ее в дистрибутив.

Людмила Николаевна, спасибо!

И появился вопрос про проверку состояния переменной G11 в chkcat.gbl от 31.03.2010 года (из состава обновления D4 для ИРБИС64 2009.1)...

Прикрепляем тестовый пример...

Дополнение: понял, что тестовый пример неправильный, пока что его удалил.



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