Помогите пожалуйста разобраться! Совершенно непонятная ситуация. Выполнила обычную проверку. Проверка БД Каталога ошибок не выявила, а проверка БД Читателей выявила 21 ошибку. Но я совершенно не могу понять в чем ошибка! Опишу ситуацию:
Обычно мы выдаем книги при помощи автоматов (RFID-технологии). Но у нас есть ряд бумажных формуляров, которые остались еще с тех времен, когда у нас была традиционная выдача. Мы приняли решение (чтобы эти экземпляры не числились свободными и чтобы "отловить" старых должников) записать эти книги на читателей. Делаем просто: через АРМ Книговыдача -Выдача без заказа - находим книги по инвентарным (они же регистрационные) номерам и выдаем читателю.
Уже обработали так 181 должника. И вот у части из них и показывает ошибку "неверный статус экземпляра" (см. протокол проверки в прикрепленном файле). Я проверила все 21 строчки протокола. Каждая из книг числится за тем читателем и у каждой из них ВЕРНЫЙ статус т.е. 1. Ни у одной из них дублетного шифра или номера. Прикрепляю запись читателя (мфн 1535 см. прикрепленный файл). Ему в один и тот же день оформили выдачу 9 книг. И вот на 1 и 8 пишет ошибку. Причем, книга с регистрационными номерами 1060/...(см. прикрепленный файл) несколько раз встречается в протоколе как ошибка, но каждый раз на деле ошибки нет.
Что же такое происходит? Какая на самом деле у нас ошибка?



Редактировано 1 раз. Последний раз 14.03.2016 10:31 пользователем roit.

Никакой надежды на помощь?

Подключилась к рассмотрению. Ответ - не так сразу

Спасибо! Если Вы подключились, то у нас появилась надежда :)

Добавлю информацию. Сделала очередную еженедельную проверку. Количество "ошибок", которые ошибками не являются прибавилось. Это и понятно т.к. работа по оформлению книговыдачи на должников продолжается. Но вот что странно - в новой проверке не сочтены ошибками 2 издания, которые в предыдущей проверке были (инв. номера 1211/6, 1211/7, это одно название, но выданное разным читателям). При этом, ничего за эту неделю с данными записями не делали (как оформили тогда выдачу, так они и числятся за читателями, а в базе со статусом 1). Протокол этой новой проверки прикрепляю.
А еще решила прикрепить ини-файл книговыдачи и личный ини того библиотекаря, который выдавал все эти книги (эту работу выполняет один и тот же библиотекарь). Вдруг причина в том, что мы что-то не так настроили.

Исправила задание на проверку, прилагаю, в БД RDR.
Другие замечания - проверьте с исправленным заданием.

Спасибо! Нашел только 1 ошибку - настоящую. Только вот хочу спросить - это у нас в базе были какие-то особенности, которые потребовали поправок или что-то не так было с самим заданием на проверку? Спрашиваю, чтобы понять будет ли исправленное задание в следующих версиях ИРБИСа или мне его надо будет копировать (собираемся примерно через месяц переходить на 2015 версию)?

Была заложена неверная логика именно для выявления несогласованности (остальные ошибки определялись правильно). Особенностью было наличие одинаковых инвентарей (УК1...), наличие же у них ШК и наличие как выданного такого экземпляра, так и невыданного.
Исправленный вариант попадет в обновление D2 и все последующие версии.

ochagova написал(а):
-------------------------------------------------------
> Была заложена неверная логика именно для выявления
> несогласованности (остальные ошибки определялись
> правильно). Особенностью было наличие одинаковых
> инвентарей (УК1...), наличие же у них ШК и наличие
> как выданного такого экземпляра, так и
> невыданного.
> Исправленный вариант попадет в обновление D2 и все
> последующие версии.
В версии 2018 (D2) всё вернулось обратно! Опять огромный протокол в котором записи не являющиеся ошибочными!



Редактировано 1 раз. Последний раз 27.02.2019 15:37 пользователем roit.

Татьяна Ароновна, вы приложили не ту картинку. Приложите тот самый протокол, упростите мне задачу.

Людмила Николаевна, извините! Столько ошибок в 2018 версии вот также вернулось из самых разных прежних версий, что я уже запуталась что где прикладывала. К сожалению тот протокол не сохранила, но чтобы не делать заново проверку, я прикладываю обратно тот протокол, который в 2016 Вам присылала. Он был выше, но чтобы Вам не крутить вот он.
Там же выше у Вас и файлы с решением проблемы есть. Я просто не решаюсь сама их тащить в новую версию, но Вам наверное ясно в чем была проблема. Опять же, чтобы Вам вверх не крутить прикладываю то, что Вы тогда прислали.
Если нужно, то сделаю проверку еще раз в новой версии и пришлю таки протокол, но он точно такой же, разве что номера другие за эти годы есть.

Татьяна Ароновна, проверила это задание в 2018, оно правильно работает. Но вы приложили файл chkrdr.gbl за 20160320, а в дистрибутиве 2018 и у меня он за 20160629. Почему у вас такой?
Прикладываю то, что в дистрибутиве.

Оно неправильно работает. Вот то что у меня получилось сегодня в протоколе. Чтобы доказать что неправильно работает я прикладываю еще и записи читателя и книги, которые в первой же строчке, чтобы Вы увидели что всё там правильно - книга читателю выдана, статус у нее 1. А протокол записывает ошибку и в остальных строчках протокола такая же ситуация.
Я наверное недостаточно ясно объяснила - то что я приложила это не из дистрибутива 2018, это то что Вы же мне прислылали в 2016 году с исправлением ошибок.В дистрибутиве у меня файл того же числа что и у Вас.
Вы можете персемотреть еще раз диалог наш 2016 года с самого начала который тут же выше, может Вы вспомните что там было не так и опять поправите?
Простите, если вышло будто я указываю что Вам делать, Вы лучше меня всё это знаете, просто очень нужно решить проблему до окончательного перехода на версию. Я эту проверку еженедельно провожу и если в протоколе будет столько лишнего, то она будет весьма затруднена.



Редактировано 6 раз. Последний раз 28.02.2019 16:40 пользователем roit.

Ошибку нашла, спасибо.Прикладываю исправленный файл.

Людмила Николаевна спасибо Вам большое! На той же базе сейчас провела проверку: "ошибок на обнаружено"!

Здравствуйте!
При переходе на полнотекстовую версию ИРБИС (2018.1 D5) очень сложно у нас проходил процесс индексации и создания словарей заново, по несколько дней с ошибками и запуском процесса заново, на web все не работало и не открывалось.

При этом АРМ Каталогизатор и Книговыдача работали в обычном режиме и иногда библиотекарь оформлял книговыдачу и возврат, думая, что уже можно работать в базе.

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

Но финальная индексация была у нас в конце августа-начале сентября 2019 г., возможно, там тоже возникали такие моменты, я уже не смогла это проконтролировать, тк проводила занятия с 1 курсом.

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

Заведующая поставила задачу решить эту проблему.

Сделала контроль системы книговыдачи (как я подозреваю, впервые за время работы в ИРБИС в данной библиотеке; с 2003 года!, я здесь работаю с 2017).

Программа выдала вот такие результаты.
Если по базе RDR можно попробовать разобраться, всего 3 записи, хотя там дата выдачи сентябрь 2018 г, когда о переходе на новую версию еще речи не шло.

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

Увидела исправленный файл в ветке - если у нас в базе он датирован 01.03.2019 (как здесь последнее сообщение на форуме - значит это он и есть?
Или на всякий случай еще раз его переставить и посмотреть?

Спасибо за ответ!

Какой файл вы увидели? Работает файл ChkCat.gbl и он в дистрибутиве от 06.02.2018. Попробуйте сначала опустошить БД WORK, т.к. результаты контроля пишутся туда. Потом выполните без корректировки можно на интервале MFN, например, 1-1000. Потом выполните с корректировкий. Статус 1 должен сняться с экземпляров.

Людмила Николаевна, я имела ввиду файл CHKrdr.rar, который вы прикрепляли к предыдущему сообщению на форуме.
Спасибо как всегда за оперативную помощь и поддержку!
Будем работать.

Версия 2020.1 (D3) в контроль системы книговыдачи опять ошибка. Тему я когда-то делала с названием "в чем наша ошибка", но ошибка несомненно не наша, а программы: что то не так в D3 с файлом из ibis - chkcat.gbl
Суть ошибки:
Запускаем контроль системы книговыдачи БД Каталога (БД Читателей тоже запускали, ошибок не было). Получаем протокол (см. вложение) с множеством ошибок по причине "несогласованные записи". Но ошибок нет. Или я не понимаю что теперь контроль считает ошибкой. Но несомненно эти ложные сообщения об ошибках затрудняют контроль т.к. реальные ошибки среди них чтобы выявить нужно проверять вручную весь большой список.
Все случаи списка не проверяла, проверила выборочно и у всех, что проверила статус 1 у экземпляра (выдан) и есть читатель (именно с этим мфн), у которого этот экземпляр. Прикладываю протокол и 1 случай из него т.е. запись книги и запись этого читателя
Запустила ту же проверку с chkcat.gbl, который был до обновления (от 2018 года) - ошибок не обнаружено.
Пожалуйста разберитесь с этим файлом из обновления D3 к 2020.1



Редактировано 6 раз. Последний раз 24.07.2021 14:49 пользователем roit.

Попробуйте приложенный вариант. Положите файл в SPBGUKI. Напишите.

Стало чуть меньше ошибок. Но всё еще не в порядке. Прикрепляю протокол.
Пояснения: найти должна была программа только книгу с инвентарным номером 561561 - я специально для проверки вручную сделала ей статус 1, она не выдана читателям на самом деле.
А остальные ошибки не настоящие т.е. в протоколе они значатся ошибками, но никаких ошибок не существует. Первая же книга б/н действительно выдана читателю, но его мфн не 68. У читателя с мфн 68 совсем другие книги. И то же самое касается журналов, они совсем у других читателей, а не у тех, у кого мфн 68 и 903. Т.е. эти журналы совершенно на законных основаниях имеют статус 1, но они не у тех читателей, которые указаны в протоколе. А у тех читателей другие книги.
Прикрепляю запись на 1-ю из найденных "ошибок" и запись настоящего читателя, у которого эта книга
Похоже проблема осталась с б/н и с номерами журналов (у них вместо номера инвентарного просто номер комплекта типа 1, 2, 3).



Редактировано 3 раз. Последний раз 27.07.2021 20:37 пользователем roit.

Добавлю еще т.к. я не сообразила к предыдущему посту прикрепить читателей 68 и 903 из протокола (см предыдущий тот пост), то прикрепляю их тут. Похоже механизм обнаружения ошибки такой - увидев б/н или просто номер экземпляра журнала (например, 1) программа ищет первого попавшегося читателя, у которого среди выданных есть экземпляры с б/н или номером экземпляра журнала тоже 1 и, естественно, находит несоответствие т.к. у этого читателя совсем другая книга/журнал с другим шифром.



Редактировано 1 раз. Последний раз 27.07.2021 20:45 пользователем roit.

Татьяна Ароновна, попробуйте приложенный вариант

Попробовала. Увы без перемен. Только почему-то еще 1 издание б/н-3 тоже имеющее своего читателя приписано также в протоколе другому мфн

Я не могу получить такой же результат. специально создала БД с именем вашей, загрузила ваши записи книги и читателя, у меня ошибки не обнаруживаются. Кроме того, выполнила это задание само по себе - оно не вырабатывает ошибки. См. 111. Важно быть уверенной, что вы берете именно присланное задание.
Может вы еще раз проверите какое задание у вас работает? Может сделаете такую же картинку?

Людмила Николаевна, спасибо что помогаете! Но оно таким путем и не должно у Вас воспроизводиться. Если, как я подозреваю, оно "хватает" первую попавшуюся запись читателя с б/н, то в Вашем эксперименте, когда у Вас только 1 запись читателя и 1 книги, у Вас ошибок и не получается. У Вас просто нет других записей читателей, у которых тоже книги б/н, которые были бы с мфн "меньше" и стояли в базе бы ранее правильной записи. Т.е. в моем промышленном варианте есть книга с б/н (или журнал с комплектом 1) и есть много (несколько) читателей у которых разные книги с таким же б/н или журналы с комплектом 1. И проверка именно на этом сбивается.
Я уверена, что у меня работает именно нужный файл т.к. когда я меняю его на файл от 2018 года, который был в дистрибутиве до этого обновления D3, то у меня проверка проходит нормально, без ошибок.Но картинку, которую Вы просили, прикрепляю
На картинке 2 видны все файлы и тот который последний и те, которые были раньше, переименованные



Редактировано 4 раз. Последний раз 29.07.2021 14:20 пользователем roit.

Вы все правильно поняли. Возможно, В отсутствии инв.номера и штрих-кода эту проверку нет смысла делать, а б/н это отсутствие инвентаря.
Можно, конечно, перебирать всех читателей, у которых б/н, а можно в параметре INI-файла дать перечень ИН, для которых проверку не делать. Такой параметр, например, используется в АРМе Комплектатор:
WithoutInv=б/н, б.н., б. н., Б/У, н/б$
(в технологии передачи в ЭК)

Но раньше то она делалась как-то? Ошибок же с предыдущим файлом проверки (тем, что от 2018 года) и всеми еще предыдущими не было! Можно вернуть ту технологию? Смысл проверки есть - чтобы у книги, у которой статус 1 был читатель и у журнала, у которого вообще не б/н, а комплект 1 тоже при статусе 1 был читатель. Но у них же помимо б/н и комплекта 1 есть еще и шифр, который тоже есть в записи читателя. Может в предыдущих проверках как-то он использовался?
Кстати, у журналов вообще не получится с такой технологией исключения проверки как в Комплектаторе т.к. там в поле номер экземпляра просто цифра 1,2,3 и т.п.
Мне всего-то нужно, чтобы проверка, которая работала до этого обновления опять заработала. Нельзя ли проанализировать тот файл и понять почему при такой же точно базе с 2013 по 2021 год (версии ИРБИС с 2012 по 2020) это работало, а теперь в версии 2020(D3) не работает???
Вот я его прикрепляю. Он запускается на той же самой базе каталога и той же базе читателей и никаких лишних ошибок не показывает.



Редактировано 6 раз. Последний раз 29.07.2021 16:45 пользователем roit.

Возьмите откорректированный файл. К старому вернуться не получится, т.к. изменился подход к отбору данных. Постаралась учесть ваш (не только ваш) вариант.
Пишите, если что-то будет не так.

Еще раз, пожалуйста, возьмите