Доброго времени суток друзья!

Встал вопрос касательно ГУИДов в системе 1С, расскажите пожалуйста подробнее на основании каких данных он формируется?

нажми на "Я" справа вверху.

зачем тебе?

(1) Искал, не могу найти на основании каких данных он формируется, Дата + Время + Код + еще что то там. (2) Возник вопрос, если в 2-х базах, будет идентичные объекты, гуид совпадет или нет. Может он просто как код формируется типа сначало 0000001 потом 0000002 и т.д.

(3) нет

"Искал, не могу найти" - возьми на полке такую толстую книжку

(3) Не совпадёт.

(3) Объекты, созданные в разных базах, будут иметь разные идентификаторы даже если все остальное в них будет абсолютно одинаковым.

(4,6) совпадает.
Пример есть
:)

Даже не мисте этот вопрос раз 100 обсуждался

Есть какая нибудь литература касательно ГУИДов в 1С? Отдельная статья)

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

(7) Вопрос, на основании чего он разный получится?)

(11) Да, это вполне реально.

v8: Где взять описание GUID, который в 1С 8?

+11 я на это нарвался, при переносе в общую базу, когда объеты одной базы "перетёрли" объекты другой базы при сонхронизации по внутреннему идентификатору. Базы создавались лет 5 назад из одной общей.
Пришлось делать синхронизацию по полям поиска.
:(

(12) На основании алгоритма его расчета.

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

может такое произойти что в разных базах создались 2 идентичных гуида, и скажем при переносе они встретятся (16) Алгоритм и интересует)

Спасибо(14), H A D G E H O G Описал кстати в v8: Где взять описание GUID, который в 1С 8?
GUID - ссылка - это тупо 16 байт.
Формируется по особому алгоритму, гарантирующему уникальность вновь созданных
ПРЕДСТАВЛЯЕТСЯ обычно в виде:
XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX,
где
X - представлем в шестнадцетиричном видею

Важно!

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

Важно!

GUID 1С формирует не по правилам Microsoft, а инкрементно.
В начале сеанса формируется стартовый GUID, r примеру
6F9619FF-8B86-D011-B42D-00CF4FC964F0

У каждого последующего, созданного в этом сеансе ссылочного объекта GUID будет на 1 больше, к примеру:
6F9619FF-8B86-D011-B42D-00CF4FC964F1
6F9619FF-8B86-D011-B42D-00CF4FC964F1
6F9619FF-8B86-D011-B42D-00CF4FC964F1

(18) В разных базах не могут создасться одинаковые идентификаторы.

Инкрементный гуид - это тоже по правилам, назывется
SequentialUUID

(20) Почему? Их хоть и МНОГО(2 в 128 степени), но вероятность есть)

Все рассуждения о дублях ГУИД - это городские байки, к которым пока никто не привел фактов; при этом, на 100% я уверен, что дубли ГУИД будут вызваны какими-нибудь обменами.

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

Гдето была ветка.

(24) так это давно было известно, SeqUUID все-таки не 1с придумала

(26) Не знал. Думал - Российское ноухау.

Даже в АПИ венды есть функция

(23) Если судить в пределах 1-й конфигурации, да(байки 100%), а если при обменах, то такое поведение не исключено, а если БД-х создались из 1-й, то вероятность увеличится, правильно?)

Тут вопрос: как следующий генерится. В какой момент генерируется ключевой 0 элемент.
Ну в серверной вроде при старте сервера,а в файле?

(29) Нет, не правильно. Научитесь таки различать СОЗДАНИЕ и ХРАНЕНИЕ. Дублирование есть результат не СОЗДАНИЯ, а обменов/передач/копирований и т.д.

(31) Я ведь тоже самое спросил, только своими словами: "Если судить в пределах 1-й конфигурации" - НЕТУ ОБМЕНОВ, "а если при обменах, то такое поведение не исключено, И если БД-х создались из 1-й" ОБМЕНЫ\ПЕРЕДАЧИ\КОПИРОВАНИЯ

Значит так.
Алгоритм генерации УИД-ов старается, чтобы они были уникальными, но внутри алгоритма используются параметры машины, такие как MAC-адрес и другие уникальные данные компьютера.
Но, если кто-то уникальные данные подправит так, что на двух компьютерах они будут абсолютно одинаковыми, то есть вероятность получить два одинаковых УИД-а.

(33) От MAC-адресов MS отказался, поэтому встает веселая трабла когда на клонированной винде в копии базы легко получить одинаковые гуиды в одно время если генерировать их в одно время.

(34)+ К примеру на 100 клонированных компах в одной РИБ базе 1С 8.1 на ~2 миллиона объектов (уникальных уид) смогли получить 1 совпадение.
Хотя специально не старались, просто купили кучу системников для автоматизации аптек, админы банально наклонировали винду (даже без смены лицензионных ключей), туда воткнули РИБ базы и отправили по филиалам.

Затем при работе через полгода получили 1 совпадение - документ сначала был, а потом перезатерся другим (совсем другая аптека) при штатном обмене.

(35) Если бы использовались непоследовательные ИД, то совпадений было бы меньше.

(36) Да просто желательно знать тонкости работы железа/софта и предусматривать это в своих решениях.

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

(12) Дык, это сверх секретная информация. Билл Гейтс создал его как некий ИНН масштаба вселенной, и даже не какой-то личности, а любого эл. документа, поскольку в GUID вшивается мак-адрес сетевой карты компа, на котором создан эл. документ. Так-что все мы "под колпаком Мюллера". После конечно объявили, что GUID - нарушение прав человека, и он просто случайное 32 разрядное 16-ное число для 1С-ников.

(0) https://www.ietf.org/rfc/rfc4122.txt

(35) Наверное поиск этого бага был весьма трудным) Мол, куда делся документ?

(40) Неа, там повезло что на основании этих доков делались "реестры рецептов", куда и ссылка на исходный документ и скопированы данные из реквизитов документа.

Система предназначенная для контроля изменения документов (уже отправленных на оплату) задним числом сработала штатно.

(0) я в 7.7 их формировал как MD5-хэш от ЗначениеВСтрокуВнутр()

на клонированных базах неоднократно встречался с дублированием для разных объектов. Например в периферийных. В разных базах, даже из одной конфигурации, даже при переносе данных ни разу не сталкивался.

Чуваки, 2к17 на дворе.... Хорош муйню давно переваренную перетирать

Разве может повториться случайное 32 разрядное 16-ное число? Только чисто теоретически.