Здравтсвуйте.
Версия Ирбис 64 2010.1

Осуществляли переброс в БД ЭК ...

И оно описание попало не совсем как нужно ...
Эта запись из БД комплектатора была добавлена в сведения об экземлярах Абсолютно другой записи ...

Такое происходило несколько раз подряд ...

Я вручную в Каталогизаторе удалял ошибочные сведения об экземплярах , и вновь производил перенос в БД ЭК ( несмотря на то, что ФАКТИЧЕСКИ записи такой небыло (ни автора ни названия) ... новой библиографической записи в БД каталогизатора не появлялось ... А дописывались сведения об экземплярах к другой записи. )

Единственное что их как то логически связывало - это ШК (запись которую я копировал в БД ЭК , были продолжением по ШК записи куда она копировалась) ....



т.е. У исходной записи был ШК 00000896 и 00000897 ....

И эти записи добавлялись к БИБЛИОГРАФИЧЕСКОМ ОПИСАНИЮ где ШК были 0000894 и 00000895 соответственно ... т.е. система по продолжению ШК их "кидала" не туда ... причем несколько раз ...

После 4-6 манипуляций Она перекинула данную запись нормально.


В чем была проблема ???


ЗЫ. До этого были проблемы с переносом , но как то сослались на ошибку комплектаторов и особого внимания уделять не стали.
Как сейчас выясняется напрасно.



Редактировано 1 раз. Последний раз 11.07.2012 15:30 пользователем zodiak.

Запись в каталоге ищется сначала по инвентарным номерам, затем по ШК, затем по шифру документа (поле 903). Чтобы понять по какоме признаку нашлась запись на докомплектование, надо знать как появилась запись в БД CMPL - вы ее заново ввели или перенесли из БД каталога? Приведите строку из протокола о переносе о неправильно перенесенных записях. Протокол найдите по кнопке на панели инструментов и по дате переноса.

Запись вводили заново.

И по тому как произошло проблема была именно по ШК.

Скриншот на тот момент не делал (не заострял на этом внимание).

Перенос делали путем нажатия соответствующей кнопки в АРМ Комплектатор.
(Перенос в БД электронного ЭК).

Далее возникло окно о том, в какую базу делать перенос , и указанием КСУ. (остальные пункты были по умолчанию - 1).

И потом проверяли записи.

Могу привести исходную БАЗУ комплектаторов. И привести запись , что было при переносе в БД ЭК.

С 4-го или 5-го раза запись перенеслась нормально (как новая).

В ваших записях есть повторяющиеся инвентари типа УК NNN, которые м.б. одинаковыми в разных записях. Чтобы они не участвовали в поиске записи для дописывания (а они участвуют и могут дать не ту запись), в версии 11 имеестя защита - такие инвентари можно перечислить и по ним не будет докомплектования.
В версии 12 поставлена защита от неверного поиска по шифру, когда случайно шифры записей в БД CMPL и в БД каталога совпали. Проверяется еще схожесть записей по свертке.
Желательно переходить на следующие версии

По поводу защиты понятно ...

На данный момент что делать мне ???
Ведь пернос с 4-го раза был корректен.

У нас на данный момент нет возможности обновиться (прекращена поддержка).

Я написал про свое желание обновиться в поддержку ответа пока нет(мне нужно только обновление без тех сопровождения).


>>Проверяется еще схожесть записей по свертке.
Как именно это сделать ?



Редактировано 1 раз. Последний раз 12.07.2012 10:27 пользователем zodiak.

Очень хорошо, если вы приложите БД до переноса

текушую БД комплектатора могу приложить.
Базу ЭК куда делался перенос могу предложить только ту куда делался перенос ( ввиду небольшого числа записей не делал пока сохранение БАЗЫ).

Могу привести записи которые были проблемными.

что приложить ?

Приложите, укажите номер КСУ переноса, приложите logcmpl.txt из директории irbiswrk

прикрепляю

проблема была

^CMFN=253: переносилась, запись каталога MFN=6, экземпляр Рќ/Р‘00000000973 в записи каталога уже есть, экземпляр Рќ/Р‘00000000974 в записи каталога уже есть

- тут и была проблема ... т.е. по началу не обнаружили новой записи в БД ЭК , а затем уже начали сравнение ....

Т.е. запись была ДОПИСАНА ... причем ошибочно ...

По протоколу:
1. Запись с ШК 00000896 переносилась в БД BASE6 как отмеченная, была попытка создать новую запись, но запись не была создана, т.к. в БД BASE6 уже оказалась запись с таким шифром: -894366. Разберитесь - почему одинаковые шифры? Это одинаковые записи в CMPL и BASE6? Если да, то почему в протоколе написано "не переносилась"? Больше в протоколе об ШК 00000896 ничего нет. Поясните ваш вопрос о каком-то дописывании
2. ШК 00000000973. Не вижу проблемы. Запись 253 переносилась несколько раз. Сначала вы отмечали записи, но не указывали номер КСУ для дописывания. Потом все-таки нужная запись каталога дописалась. А потом протокол стал говорит, что уже есть такой ШК. В чем проблема?

Обязательно указывайте КСУ при переносе даже отмеченных!

В разделе Часто пов-х вопросов есть заметка "Перенос описаний в ЭК". Прочитайте. Также есть заметка по поводу большого кол-ва полей 910

Шифр мы не создавали ...

По крайней мере мы не присваиваем такой шифр

Уточню этот вопрос у комплектаторов.
спасибо за подсказку

Еще раз о вашей проблеме. Действительно, у вас может неверно переноситься запись, т.к. используется одинаковое обозначение инвентарей: н/б, н/б 1 и т.д. Как раз от этого ставилась защита в версии 11. Мое предложение:
1. Взять на FTP вариант программы cirbisp_unicode.exe из irbis64_11D2.zip. А в irbisp.ini добавить параметр
WithoutInv=б/н, б.н., Б/У, н/б, н/б 1, н/б 2, и тд
Т.е. перечислить те инвентари, которые повторяются в разных записях и по которым нельзя искать запись
2. Инвентари типа УК NNNN не повторять в разных записях, в одной можно

ochagova написал(а):

> cirbisp_unicode.exe из irbis64_11D2.zip

Оно нормально встанет для 2010.1 ??

> WithoutInv=б/н, б.н., Б/У, н/б, н/б 1, н/б 2, и тд

В конце ничего ставить не нужно просто оканчивается к примеру н/б 99999 ?



Редактировано 1 раз. Последний раз 17.07.2012 16:50 пользователем zodiak.

Встать должна нормально, может спросить какие-то недостающие файлы. Об этом мне напишите.
В конце ничего не надо, чувствую, что надо вводить вариант маскирования, типа н/б*

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

MFN=1725: переносилась, в БД каталога более одной записи по запросу "IN=B00445053"+"IN=B00445048"+"IN=B00445045"+"IN=B00445049"+"IN=B00445320"+"IN=B00445626"+"IN=B00415988"+"IN=B00445263"+"IN=B00445432"+"IN=B00445289"+"IN=B00445133"+"IN=B00445468"+"IN=B00445398"+"IN=B00443801"+"IN=B00445395"+"IN=B00445599"+"IN=B00454946"+"IN=B00453209"+"IN=B00454967"+"IN=B00454961"+"IN=B00454962"+"IN=B00454968"+"IN=B00454971"+"IN=B00454973"+"IN=B00454969"+"IN=B00453208"+"IN=B00453221"+"IN=B00454970"+"IN=B00453210"+"IN=B00453220"+"IN=B00575991"+"IN=B00575990"+"IN=B00575989"+"IN=B00575988"+"IN=B00575987"+"IN=B00575986"+"IN=B00575985"+"IN=B00575984"+"IN=B00575979"+"IN=B00575983"+"IN=B00575982"+"IN=B00575981"+"IN=B00575980"+"IN=B00575978"+"IN=B00575977"+"IN=B00662677"+"IN=B00662732"+"IN=B00662730"+"IN=B00662724"+"IN=B00677334"+"IN=B00676770"

Есть MFN из базы CMPL, MFN из базы ЭК не отображается. Тут проблема в том, что по этому запросу находится не одна запись, а несколько. Это говорит об ошибке, но сразу же выяснить в какой именно записи эта ошибка не получается. Можно добавить в конец такой строки в скобках перечисления MFN всех откликнувшихся записей?

Протокол формируется програмно. Хорошо, я добавлю список MFN, в первом же выпуске 2012 это будет

Огромное спасибо! Это поможет быстро и однозначно идентифицировать ошибочные записи.