Имеем такой случай, берем документ, создаем в базе1, меняемся с базой2, в базе2 редактируем документ из базы1, сохраняем, меняемся с базой1, и в базе2 имеем устаревший документ который был в базе1, это доставляет очень сильно пользователям положительных эмоций. Причем это происходит, нерегулярно и проследить закономерность не получается. Что с этим делать, как отследить и как исправить, может сталкивался кто?

(0) Планы обмена используете при обмене? А правила обмена? Ручная регистрация изменений? Вообще, обмен самописный или типовой?

Коллизия

(1) Обмен типовой, Ут 10.3 магазины меняются с центром, сегодня пользователь был очень расстроен, из-за того что два дня работы было потеряно.
(2) А что делать?

+(3) ну как типовой, слегка подшаманен, торговове оборудование не выгружается, настройки пользователей, свои документы справочники добавлены, в целом больше ничего от типового не трогали

Доброе утро. не понятно почему в базе2 устаревший документ. Раз последняя правка была в базе2,значит при обмене с базой1 все правки должны перейти в базу1 и документы база1 = документы база2.

(3) Запретить, или, по крайней мере, свести к минимуму изменение документов в двух базах. Одни документы создаются и редактируются в одной базе, другие в другой.

(5) Очень просто: за время между обменами документы были изменены в обоих базах. Применяются изменения из центральной. Изменением, кстати, считается и простое нажатие ОК для закрытия документа. Скорее всего, именно это и происходит.

лучший способ - избавиться от РИБ

(7)Но автор не говорит о том, что правка одного и того же документа происходит в одно время.

(9) У них, судя по всему, очень редкие успешные обновления, так что "одновременно" - понятие весьма растяжимое.

(10) я бы посоветовал автору сократить период обмена

(11) Это все полумеры. Лучше запретить пользователям изменение проведенных документов, чтобы они почем зря на ОК не жмакали.

кто последний, того и тапки... это очевидно и логично.

(13)в народе тапки обычно первого, а вот кто последний тот и отец эт да

(9) Судя по чему редкие успшные обновления? Всегда все ок было, это только второй случай, но как бы очень критично вышло в этот раз
(12) Почти что невозможно
(13) как бороться

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

2(15) сначала определить где изменения важнее потом реализовать эту важность при помощи язка в программе.. Можно воспользоваться либо систмой прав (например чтоы менеджер не мог менять не свои документы) либо вообще индивидуальной датой запрета редактирования.

2(15) Если очень критично, то тогда ты поднимаешь архив сделанный в нужном узле до обмена, вытаскиваешь документы при помощи обработки выгрузказагрузкаданныххмл81.епф, и грузишь полученный ХМЛ сразу в центр.

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

(15) Ну а на вкладке "Коллизии" этот документ есть?

(20)пустой список

Юзер говорит, что номенклатура специфичная для магазина и трогать ее вроде как никому не надо а половина из измененной им таки потерлась и стала как было до редактирования, таже история что и с документом, посмотреть пока нет возможности трогали ее  или нет

Имхо: обмены должны проводится регулярно, по расписанию и... как бы это сказать правильно... - сеансами обмена. "Сеанс обмена" - это взаимные обмены. примерно так: выгрузка данных из ЦУ -> загрузка данных в ПУ -> выгрузка данных из ПУ -> загрузка данных в ЦУ.

"Восстановление" объектов в риб-базах? Да запросто :) По каким-либо причинам в центральном узле пропущен приём сообщения от подчиненного узла.

Пример: изменили объект - выгрузили в подчиненный узел. В подчиненном узле - приняли и внесли изменения в объект. Из центрального узла вновь выгрузили изменения и вновь их приняли в подчиненном узле. Всё - объект "восстановлен" до своего "предыдущего" состояния.

(21) Ну тогда проводите следственный эксперимент.

(22) Тоже считаю, что просто одни и те же документы меняются в обоих базах между обменами... Это недопустимо. Бери линейку бей всем по рукам.

(26)торговый зал 6 компов, 15 человек персонала, продажи идут очень активно люди в зале есть почти всегда, в связи с тем что работает терминальный сервер, работа идет в режиме один комп - один юзер(приходится разводить компорты на сканерах по имени пользователя которое идентифицирует имя компа) то есть вычислить какой юзер поменял документ - невозможно, только какой комп.

чуть позже есть мысль бейджиком со штрихом потверждать важные операции записи, пока работаем в таком режиме

(23) это так и происходит, какой смысл делать иначе?

(29) Не факт. Перепроверь. История обменов хранится в базе.

(27) Они что у тебя, под одним пользователем все работают?

один комп - один юзер в базе

(32) Тогда почему ты пишешь в (27) "то есть вычислить какой юзер поменял документ - невозможно, только какой комп"?

(33) я немного неправильно выразился: один комп - одна учетная запись в базе, компов 6 - продавцов 15, своя учетка тока у бухов, дира и у меня.

(34) Да, походу, ты сам не до конца понимаешь, что говоришь))
Если "один комп - одна учетная запись в базе" и "компов 6", то у тебя в базе ШЕСТЬ учеток. Учитывая, то "продавцов 15", то я повторяю свой вопрос (31)!

(35) Ты удиительно проницателен КЭП ) ты все правильно понял в этот раз, но дела это не меняет

(36) Так какого фига, они у тебя под одним пользователем работают-то? Пусть каждый работает под своим пользователем...