Какая вероятность совпадения внутреннего ИД элементов справочника? #588231

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

а как, пардон, видно? по мак-адресу сравнивал?

А причем тут код?

А могло это случится например создали в дочки, в центре поменяли организацию в договоре, вот оно и ушло в другую дочку

Ну код РИБ базы #1:ААА Второй: БББ Как мог попасть (или кто мог создать елемент) в базе №1 с кодом: БББ0000130 и владелец организация с префиксом ААА. Вроде исключено, центр только для анализа и сбора общей статистики по двух фирмах, используется только для чтения. Хотя по логах проверю сейчас, а то ж ручки шаловливые встречаются :)

код != внутренний ИД

за это в курсе, просто другого пока объяснение не вижу, из-за чего такой глюк может случиться: создаем в двух дочерних база елементы новые, и "случайно" у них генерится тот-же код гуид, после обмена и получается такой при(о)кол, и они склеиваются в один :(

Смотри по журналу регистрации где был создан и какой изначально был код Если гуид "совпал" то в обоих дочках будет запись о создании. Также смотри автора (если кончено у тебя обмен идет под другим пользователем)

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

не просто исчезающе мала, а безнадежно бесконечно мала - доказано уже - в архивах ищи и на других ресах. Если гуиды совпали, то это проблема кода при обмене или заблуждение. Преобразуешь "подозрительные" гуиды в хмлстрока и сохраняещь или в отладчике копипастишь. потом в обеих базах проверяешь поиском ссылки по гуиду кто-же(какая ИБ) их породили. Если будет обнаружен дубль, то это обмен, хотя недавно писали и про бзики скуля, но это другая история

очень умный юзер мог создать, скопипастив гуид в буфер из одной базы и запустив в другой базе обработку в пару строк .... Объект.Записать;

+ что касается кода и префикса, то это еще проще

Вообще в семере этого избегали очень просто, часть внутренного ид содержала код базы в которой создан. В двух разных базах одинаковый не создашь никак. Неужели в v8 отказались от столь простого и надежного решения? ;)

хотя хрен сработает)

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

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

+ Хотя тут что под названием GUID понимать конечно. Раньше это была часть ID, в терминологии v8 возможно весь ID GUID'ом обозвали.

Нету сейчас этого

Не поверишь, у меня справочник контрагентов и номенклатуры выгружается из 7-ной базы со своим ГУИД, т.е. я могу загрузить в любую почку и он не задвоит справочники А так да напрямую код в может не сработать ибо представления и как оно там хранится - разной. 1С каверкает ГУИД

GUID 1С-а представленный в 1С, например Сообщить(Строка(Ссылка.УникальныйИдентификатор)); отличается от фактически хранимого в базе на некоторые перемешанные значения Например, в 1С он выглядит как 6F9619FF-8B86-D011-B42D-00CF4FC964FF В базе (фактически) он имеет значение: 6F9619FF-D011-8B86-B42D-00CF4FC964FF (Это тупо пример, там алгоритм перестановки другой, лень споминать) Важно! GUID 1С формирует не по правилам Microsoft, а инкрементно. В начале сеанса формируется стартовый GUID, к примеру 6F9619FF-8B86-D011-B42D-00CF4FC964F0 У каждого последующего, созданного в этом сеансе ссылочного объекта GUID будет на 1 больше, к примеру: 6F9619FF-8B86-D011-B42D-00CF4FC964F1 6F961A00-8B86-D011-B42D-00CF4FC964F1 6F961A01-8B86-D011-B42D-00CF4FC964F1 (c)

А вот это интересно, при таком инкрементном формировании, если чем подольше 1С не закрывать, вероятность совпадения тогда увеличивается

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

Отвечу по порядку. 1. Вероятность очень низкая, но она есть. 2. У тебя скорее всего косяк с обменом и загрузками, и с этой вероятностью не связано. Уже не первый раз виду программиста который задается вопросом таким, всегда это при разборе оказывался косяк программиста, а не "вероятность"

Почему это не сработает ?

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

В стандартном GUID (CoCreateGuid) есть возможность генерировать некоторое конечное количество GUID с одной отметкой времени, и они действительно не сильно различаются - возможно, что именно этот алгоритм и использовали - то есть генерируют сразу какое-то большое количество GUID, а потом их просто используют, когда нужно - это проще, чем для каждого GUID вызывать алгоритм генерации, который на системном уровне требует синхронизации потоков, чтобы не было одинаковых GUID. А переставлены они, скорей всего, из-за того, что используют unsigned long[4] вместо стандартной структуры GUID - там как раз два unsigned short местами переставятся.