Переносим запись в бд IBIS, добавляет одинаковый номер (как видно на скриншоте "стало") и кидает то в одну запись то в другую (Иногда кидает в другой MFN скриншот "Сюда тоже кидает"). Подскажите в чем проблема?

OMEN написал(а):
-------------------------------------------------------
> Переносим запись в бд IBIS, добавляет одинаковый
> номер (как видно на скриншоте "стало") и кидает то
> в одну запись то в другую (Иногда кидает в другой
> MFN скриншот "Сюда тоже кидает"). Подскажите в чем
> проблема?


Покажите запись,из экземпляры которой переносите из CMPL. Что собирались переносить?
Поле 910^C неверной структуры. Должно быть 8 цифр.

Вот запись.

OMEN написал(а):
-------------------------------------------------------
> Вот запись.


Вы в файле было.JPG (207.4KB) видны все те же инвентари, что и в запись.jpg. Правда у тех инвентарей, что приписались повторно не было номера КСУ. Так что же нового Вы хотели передать?

напутал со скриншотами... короче так. В CMPL было 3 строки вот такие

КХр (15.06.2010г., Инв.ar70126, N КСУ 2010/20 1-Е ПОЛ. ДИСС. АВТОРЕФ., Цена )
КХр (15.06.2010г., Инв.ar70127, N КСУ 2010/20 1-Е ПОЛ. ДИСС. АВТОРЕФ., Цена )
КХр (15.06.2010г., Инв.ar70288, N КСУ 2010/20 1-Е ПОЛ. ДИСС. АВТОРЕФ., Цена )

в IBIS было только 2 из них. Но вместо того что бы добавить одну оно добовляет все три и в итоге получается 5 сторк

OMEN написал(а):
-------------------------------------------------------
> напутал со скриншотами... короче так. В CMPL было
> 3 строки вот такие
>
> КХр (15.06.2010г., Инв.ar70126, N КСУ 2010/20 1-Е
> ПОЛ. ДИСС. АВТОРЕФ., Цена )
> КХр (15.06.2010г., Инв.ar70127, N КСУ 2010/20 1-Е
> ПОЛ. ДИСС. АВТОРЕФ., Цена )
> КХр (15.06.2010г., Инв.ar70288, N КСУ 2010/20 1-Е
> ПОЛ. ДИСС. АВТОРЕФ., Цена )
>
> в IBIS было только 2 из них. Но вместо того что
> бы добавить одну оно добовляет все три и в итоге
> получается 5 сторк


В любом случае, эти 2 экземпляра передаются повторно. Они же были в каталоге до передачи по КСУ 2010/20. В CMPL этим двум экземплярам приписан тот же номер КСУ, который подлежит передаче. Вот они и приписываются повторно. В последних версиях этого уже не происходит, а выдается сообщение, о том, что такие экземпляры уже есть в каталоге.
У Вас, видимо, старая версия, поэтому, сообщение, возможно, другое.
А вот как у вас в каталоге образовались экземпляры без КСУ с неправльной датой поступления, не знаю.

С датой так решили наши библиотекари... они проставляют только год. А на что дата может повлиять в дальнейшем?Кстати проблему решил удалив все сведения экземпляров из записи в ЭК и перенес запись опят.



Редактировано 1 раз. Последний раз 13.02.2012 11:53 пользователем OMEN.

Перешли на версию 2011.1(32). Когда много записей в ксу, комплектаторы при переносе не ставят "актуализировать". При этом выдается сообщение "is not a valid integer value" и переноса не происходит. Что за ошибка?

Замените в директории CMPL приложенные файлы.

Добрый день! По предыдущему вопросу все получилось. Возник еще один, по переносу партии. Чтобы быстро выдать книгу,каталогизаторы делают краткую запись. При этом шифр документа остается случайным числом. В комплектовании при вводе новой записи тоже формируется случайный шифр.Иногда он совпадает (бывает). при переносе проверяя шифр, приписывается не к той записи. В версии 10.1 если так случалось, было сообщение "ЗАПИСЬ НЕ СОЗДАНА - Ошибка : Дублетный шифр -". Можно сделать и в версии 11.1(ирбис32) также.

Здесь вопрос в другом. Можно ли пользоваться шифром записи для обнаружения этой же записи в БД каталога, чтобы запись каталога дописать новыми экземплярами?
В пред.версиях шифр при переносе не использовался, поэтому запись создавалась как новая, но ФЛК давал ошибку.
Но часто возникали ситуации неправильных действий - запись бралась в ЭК, переносилась в БД CMPL, и неверно убирались прошлые экземпляры. Это приводило к тому, что при переносе не за что было зацепиться и эта запись шла как новая. Было много жалоб, что должно быть дописывание, а вместо этого создаются новые записи.
Сейчас, если нет экземпляров, то поиск записи на дописывание (в последнюю очередь!) идет по шифру, иногда вызывая вашу ситуацию.
Здесь надо выбрать меньшее зло.
Может при поиске по шифру подключать еще свертку или некий набор полей?

Дело в том, что наши комплектаторы не переносят записи из каталогизатора, у нас не опустошается бд CMPL и экземпляры у нас всегда есть. Посоветуйте нам как быть? Можно ли самим сделать так, чтобы не использовался шифр при переносе?

Я, конечно, могу запараметрировать возможность переноса по шифру, но это будет только в следующей версии (12.1). А пока можете сделать так, чтобы шифр, создаваемый в БД CMPL, никак не мог совпасть с шифром, созд. в БД каталога. Например, в autoin.gbl БД CMPL найдите строки
ADD
903
XXXXXXXXXXXXXXXXXXX
А в этой строк найдите ткст &unifor('R') и замените его на 'K',&unifor('R') (он в этой строке в 4-х местах)