При сохранении в АРМе Каталогизатор откорректированной записи может возникать сообщение:

"Несовпадение версий записи. Данные Вашей версии ВРЕМЕННО сохранены в архиве (<Alt>-A). Проверьте правильность автоматического слияния двух версий записи..."

это означает, что пока проводилась данная корректировка данная запись была изменена другим клиентом (в АРМе Каталогизатор ИРБИС64 БЛОКИРОВКА корректируемой записи НЕ ПРОИЗВОДИТСЯ). При этом система выполняет следующее:
1. НЕ СОХРАНЯЕТ в БД корректировку "опоздавшего" (данного) клиента
2. Сохраняет эту (данную) корректировку в архивном буфере клиента (вызывается по Alt-A)
3. Осуществляет АВТОМАТИЧЕСКОЕ СЛИЯНИЕ двух версий записи - реальной (от "опередившего" клиента) и "опоздавшей" (той, что в архивном буфере) - и результат слияния представляет в РЛ у данного клиента, предлагая его проверить (т.е. в БД он не сохраняется - см. п.1)

Если результат АВТОМАТИЧЕСКОГО СЛИЯНИЯ не устраивает данного клиента, он должен нажать кнопку ОТМЕНИТЬ и запись примет реальный вид (т.е. тот, что в БД)

Теперь по поводу АВТОМАТИЧЕСКОГО СЛИЯНИЯ - оно проводится по АБСОЛЮТНО ФОРМАЛЬНОМУ алгоритму: НЕПОВТОРЯЮЩИЕСЯ поля заменяются (последняя рука у "опоздавшего"), а ПОВТОРЯЮЩИЕСЯ поля логически суммируются (т.е. оригинальные значения поля добавляются). Такой алгоритм слияния может приводить к "дурному" результату - особенно если корректировки обоих клиентов (опередивщего и опоздавшего) касались экземпляров (910 поля) - ПОЭТОМУ НЕОБХОДИМО ТЩАТЕЛЬНО ОЦЕНИВАТЬ РЕЗУЛЬТАТ СЛИЯНИЯ прежде, чем его сохранять.

Есть предложение запараметрировать факт АВТОМАТИЧЕСКОГО СЛИЯНИЯ, т.е. ввести параметр AutoMerge
AutoMerge=1 ДЕЛАТЬ автоматическое слияние
AutoMerge=0 НЕ ДЕЛАТЬ автоматическое слияние

По умолчанию предполагать AutoMerge=0



Редактировано 1 раз. Последний раз 28.02.2007 15:39 пользователем Alio.

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

А то, что управление данной функцей нужно выносить в ini - без сомнения. Вот только я не могу предположить - в какой (клиентский или серверный). Вроде и то и другое может потребоваться.

Полностью согласен с Александрами Иосифовичем и Сергеевичем :) Параметризировать - желательно. Раскрашивать - очень желательно, поскольку сам когда сталкивался с такой ситуацией, то сложно разобраться что и откуда. Особенно сложно, а точнее невозможно, оценить неповторяющиеся поля: архиве МОЯ запись, на РЛ автоматически же в неповторяющихся полях - МОИ данные. Т.е. все равно нормальный человек должен 100% нажать ОТМЕНА, чтобы знать что там было сделано "конкурентом". Еще момент - в архиве хорошо бы все-таки сортировать по меткам полей. Именно для удобства отслеживания

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP

Насчет раскрашивания - это ВЫ хватили... В ИРБИС НЕ ОТСЛЕЖИВАЮТСЯ ИЗМЕНЕНИЯ на уровне ПОЛЕЙ - только на уровне ЗАПИСИ

ну а что мешает это сделать? :)
во всяком случае нам помечтать-то не вредно

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP

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

Мне кажется логичным примерно следующий алгоритм (при отключеном автослиянии).
1. Клиент работает, вносит изменения в свою локальну копию записи
2. Сохраняет, но сервер фиксирует его "опоздание", после чего возвращает ему актуальную версию записи. Клиент при этом сбрасывает свой вариант в архив с сортировкой полей по числовым меткам (можно было бы сразу в буфер, но вдруг у него там уже что-то есть, так что в архив)
3. В архиве проводится анализ на несовпадение полей актуальной записи и содержимого архива. Красным (допустим) цветом выделяются те поля которые не совпадают по содержимому, либо отсутствуют в актуальной записи.
4. Оператор открывает архив и просто сразу фиксирует свое внимание на цветовых выделениях тут же сравнивая их с содержимым полей в РЛ.
5. Принимает решение о сбросе (либо нет) архива в буферную запись
6. Редактирует буферную запись
7. Вставляет данные из буферной записи

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

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP

В интерфейсе работы с буферной записью можно сделать режим: СРАВНИТЬ С ТЕКУЩЕЙ ЗАПИСЬЮ (В РЛ)...

> В интерфейсе работы с буферной записью можно сделать режим: СРАВНИТЬ С ТЕКУЩЕЙ ЗАПИСЬЮ (В РЛ)...

Пусть так, а что она показывать будет? Три цвета (одинаковые-черный; несовпадающие - от старой - синий (то, что сотрется), несовпадающие от новой - красный (то, что добавится)) или два (совпадающие - черный, несовпадающие - красный)?

Мне кажется что вполне достаточно просто двухцветки. Это и сделать проще (все-таки сравнивать надо лишь 2 а не три варианта записи), да и по логике оператор все-таки должен в общих чертах помнить что он делал с записью :)

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP

Ну, положим, цвета тут ни при чем. Есть "галочки" для отметки...
В интерфейсе буферной записи будет режим СРАВНИТЬ И ОТМЕТИТЬ: будут сравниваться запись в буфере и запись в текущем РЛ и ОТЛИЧАЮЩИЕСЯ поля и там и там будут отмечаться...
(При сравнении повторяющихся полей их номер повторения НЕ БУДЕТ учитываться)

> Ну, положим, цвета тут ни при чем. Есть "галочки" для отметки...

Если "галочки" наскучат по причине неудоства, потом все равно придется организовывать цветами.