Есть распределенная база. В подчиненной только свои документы, в главной все. В главной есть некий документ по головной организации, в подчиненке его физически нет. Сегодня документ головной организации пропал. Произошло это очевидно после обмена с подчиненкой.
Я посмотрел УИД документа по головной организации в выгрузке БД на начало недели и запустил поиск по УИДу в рабочей. Документ нашелся, вид документа тот же, но это уже вчерашний документ пришедший с обменом из подчиненной базы?!?! Повторюсь, у них есть только свои документы и переделать существующий документ по головной организации они не могли никак!
Получается что сгенерированный программой УИД задваивается??? Получается так можно кучу документов похерить? Как с этим бороться?

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

(0) ЖР подтверждает это предположение? Посмотри в обоих базах кто и что делал с этим документом.

(1) в смысле? в главной этот документ тихо себе лежал с января, а тут с обменом приходит документ с таким же уидом. как так?

А не мог кто-нибудь умный переделать документ, пришедший с периферии, на головную организацию? Если б такое произошло, то документ мог существовать в обоих узлах какое-то время, пока его не хлопнули на периферии, а следом при обмене - и в центре.

(2) ЖР по головной подтверждает. Последнее изменение в январе, и следом изменение при загрузке сообщения из подчиненки пару дней назад
(4) не вариант. к тому же документ не "хлопали", а как бы целиком "переделали", причем те, у кого доступа к нему не было...

(5) Смотри ЖР в периферийке, как там появился этот док.

(5) Пришел из центра он скорее всего

Правила обмена могут сыграть злую шутку. Один юзвер исправит реквизиты так, что документ не должен был, но будет включен в обмен и доставлен в другой узел, где другой юзвер может "перебить" его под свои цели...

(0) было аналогичное:
v8: Какая вероятность совпадения внутреннего ИД элементов справочника?
Схлопнулись после обмена(по организации) из двух РИБ в одной ЦБ два елем.справочника договоры из дочерних.
Но мне никто не верит :)

"вера" и "вероятность" - как бы... Вероятность есть, что на выходе мне на голову упадет кирпичь. Но не верю! Откуда кирпич, если здание панельное? :))

(9) И правильно делают, что не верят

(7)(8) нет. не этот случай. у меня есть где-то месячная выгрузка подчиненки - там все "чисто". В главной документ не менялся с января(по данным ЖР), так что "просочиться" случайно не мог никак. В выгрузке на начало этой недели тоже все нормально... так что остается только неутешительный вывод:(

(12) ЖР в подчиненной что говорит?

(10)(11) Не из фантастики: всегда есть вероятность узнать даже самый длинный пароль 5 летнему малышу хоть на сайт админки пентагона :)
Аналогично и из ГУИДом, маленькая но есть вероятность создания одинакового, так как создание идеального генератора случайных чисел еще не придумали.
Кто придумает получит наверное Нобеля)

(14) вероятность-то есть, но с вероятностью 99% это у ТС пользователи накосячили. А он ушами прохлопал.

Могу расказать прикол :)

  После сбоя в БД (иелочь, но неприятно) прибегает юзвер с криками "У меня важный документ пропал, вся отчетность сбилась..." Ну, думаю, началось... этот сбой мне боком выйдет...
  И смех и грех: ошиблись и дату поменяли на прошлый год, а номер - сам поменялся по правилам автонумерации. Вот они и потеряли документ. А один слишком умный юзвер, втихаря, набил новый документ и ручками занёс номер пропавшего документа.
  А я два часа угробил, разбираясь с ЖР в двух базах, понимая, что я что-то "не понимаю" :(

(14) как говорится более вероятно что в результате столкновения двух молекул в открытом космосе образуется тупой 1Сник

(5) может этот документ в позапрошлом году создан? А потом переделали на январь какие-нибудь ушлые товарищи. Почему вы смотрите только с января?

Тс, кстати, можно по гуиду время создания документа узнать. И если в ЖР запись о создании документа сильно отличается от времени ссылки - то кто-то сильно ошибается в своих рассуждениях :)

(19) это как? узнать время создания документа да еще по Гуид? о_О

v8: Фактическая дата создания документа 8.1 ЗУП

Функция ДатаСозданияСсылки(Ссылка)
   ГУИД = Ссылка.УникальныйИдентификатор();
   Строка16 = Сред(ГУИД, 16, 3) + Сред(ГУИД, 10, 4) + Сред(ГУИД, 1, 8);
   Разрядность = СтрДлина(Строка16);
   ЧислоСек = 0;
   Для Позиция = 1 По Разрядность Цикл
       ЧислоСек = ЧислоСек + Найти("123456789abcdef",Сред(Строка16,Позиция,1))*Pow(16,Разрядность - Позиция);
   КонецЦикла;
   ЧислоСек = ЧислоСек / 10000000;
   Возврат Дата(1582, 10, 15, 04, 00, 00) + ЧислоСек;
КонецФункции

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

ТС, опять кстати :( позднее зажигание, сори :)

При разборе полетов, в ЖР обязательно(!) должны быть видны колонки с объектом и его представлением. Запись, где номер,дата документа <> номер,дата представления - факт "перебивки" номера, даты юзвером - вот он, сам себе злобный буратино :(

(23) Из личного: v8: v8: Одна из записей в журнале регистрации поставила в тупик... "я плакаль"(с)

(0) По сути это 2 разных базы. При создании нового документа платформа генерит уникальный УИД (ссылку) в пределах базы.
Т.е. есть вероятность, что в периферийной базе мог получиться УИД, который уже есть в центральной (и в периферийную никогда не приходил).

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