какова вероятность генерации одинакового УИД объекта в двух разных базах 1с? #705658

Ну собственно интересует числовое значение. На сколько она ничтожна. И второй вопрос было ли такое куго нить на практике?

у меня было на практике 1 раз, вероятность в цифрах - хз, ОЧЕНЬ мала

ни разу не было може просто пробирки надо чище мыть :)

Maxus43 есть возможность программной установки и переноса УИД. Может это был тот случай?

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

LOL

мы анализировали эту ситуацию. По записям Версионирования были созданы 2 документа с одинаковый УИД в разных базах разными пользователями без права запуска внешних бработок и с порезанными правами. Других объяснений не нашли

Значит что-то не учли.

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

Скажем так, вероятность того, что это действительно тот самый случай... :))

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

+ GOOGLE GUID (Globally Unique Identifier) — статистически уникальный 128-битный идентификатор. Его главная особенность — уникальность, которая позволяет создавать расширяемые сервисы и приложения без опасения конфликтов, вызванных совпадением идентификаторов. Хотя уникальность каждого отдельного GUID не гарантируется, общее количество уникальных ключей настолько велико (2128 или 3,4028?1038), что вероятность того, что в мире будут независимо сгенерированы два совпадающих ключа, крайне мала. Тем не менее, случаи совпадения известны: на системе Windows 95 GUID’ы ярлыка запуска DOS-программ (.pif) и программы ZipMagic 2000 совпадали.

И не забываем что ГУИД 1с - намного примитивней ГУИДа винды, он генерится 1 раз, потом обычный инкремент. генерится 1 раз на время работы (сервера 1с, процесса или ещё чего)... Опять же вероятность очень очень мала, с этим никто и не спорит

Мы же про 1С говорим, а у неё все через... вообщем не так как в других программах

это пасхалка )

на этом форуме 2 раза видел темы, где авторы уверяли, что задвоились   гуид.

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

это я и был 2 раза :)

~10^-15

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

10 в -12 степени

+ не, вру, и без меня тут обошлось, много источников, вот миста например

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

Можно ли считать что вероятность достаточно мала что бы не придумывать дополнительную защиту от задвоения УИД?

да можно считать, что вероятность  мала .

конечно

а вот и надо. Одинаовые конфигурации на разных заводах. У организации сгенирировался один guid. Вот потом были проблемы с сливом информации в консолидацию

скажи это , он самый упёртый)

22+ Алгоритм, который Microsoft использовала для генерации GUID, был широко раскритикован. В частности, в качестве основы для генерации части цифр GUID использовался MAC-адрес сетевого адаптера, что означало, например, что по данному документу MS Word (также получающему при создании свой уникальный GUID) можно было определить компьютер, на котором он был создан. Позже Microsoft изменила алгоритм таким образом, чтобы он не включал в себя MAC-адрес А вот 1С своей инкроментацией Гуида значительно увеличивает вероятность коллизий

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

Мне кажется, что 1С сосредоточились на том, чтобы исключить дубли в пределах одной базы. А снаружи - как повезёт.

там точно дата и время завязана. я видел востановление даты по идентификатору - что мне совсем не понравилось.

Ну получается пока только у Maxus43 на практике был зарегистрирован случай... Maxus43 какие последствия были?

"чтобы исключить дубли в пределах одной базы. " так и есть. , вероятность достаточно велика, т.к. ГУИД уникален только в пределах одной базы. А в других базах - генерится все по тому же алгоритму (отнюдь не случайное число): вид объекта - вид документы - что-то еще. И вероятность - где-то 1 на 100 тыс объектов в совокупности по двум базам.

да никаких серъёзных, ибо заметили. Создали новый док и всё. Как заметили -

в РИБ есть более серъёзные проблемы с РАУЗ например, там ключи аналитики под него не приспособлены. Как вариант - генерить для новых гуид по своему алгоритму. 1с сама отказалась от этого, ссылаясь на "что математические никакие алгоритмы формирования гуида не гарантируют 100% совпадения"

тогда ведите5  учёт в  тройных GUID id base id MetaObject id Object в пределах одной  базы  GUID  всё таки уникален

Вот больше всего интересует это "что-то еще". Склоняюсь к тому, что это тупо номер сеанса пользователя. Вероятность одномоментного создания в двух разных базах документа одного и того же вида в сеансах с совпавшими номерами относительно невелика. Но вполне реальна, что и наблюдается.

вы шо, в разных сеансах делайте одновремено Сообщить(Новый УникальныйИдентификатор) - и поглядите на него, он инкрементируется, пофиг на вид документа или сеанс

Можно использовать Новый УникальныйИдентификатор в УстановитьСсылкуНового Будет честный GUID

Создание произвольного идентификатора и идентификатора конкретного объекта - не одно и то же. Я когда создавал доки с двух разных сеансов - получал разные префиксы.

Новый УникальныйИдентификатор) не инкрементируется Инкрементируется только УИД ссылок

точно? сделай сообщить(Новый УникальныйИдентификатор) 3 раза, он инкрементируется

Вроде да. Еще когда знакомился с 8.0 пытался исследовать вопрос. Сделал в табло. Не инкрементируется.

Да делал Вот пример в цикле Для сч=1 По 10 Цикл 9fe052aa-7603-43af-87d9-f9c7a18d5cd3 78eb4b48-1e78-4362-8835-47a4c85bdf9c 6cf3611d-e69f-4328-a658-38f0ae48ce12 ca56ce36-d690-495b-b1c5-95507289779b f621f599-7d6c-442f-beb0-92e56a5cdf6a e95fb206-6748-4b3c-b611-0e677e096b0a 899d2d33-ee09-4848-8eeb-5e435acdab49 7dcb1728-3148-47a7-9c16-f6f7ff8b76e6 101e88be-1779-4728-8676-9af615d48990 Покажи где инкремент При этом и дата не вытаскивается как в

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

Кстати, это легко проверить. Щаз попробую...

сдаётся мне что меняют правила генерации гуида в платформах, на 8.1 делал - инкрементился... ничо не понимаю ужо. Или от файловая клиент-сервер ещё зависит? я запутался...

Похоже на то, что я прав. Первые два - один вид документа, вторые два - другой. Созданы по порядку: 9273d422-c562-11e3-868a-00155d00a5a9 96f9ede2-c562-11e3-868a-00155d00a5a9 9cacf720-c562-11e3-868a-00155d00a5a9 a1b7641c-c562-11e3-868a-00155d00a5a9

Я перестал что-либо понимать. Создаю в новых и разных сеансах - префикс тот же самый. Щаз на рабочей базе гляну...

Сразу можно предположить, что одну базу сделали на основе другой, либо имел место перенос данных. Проверь! Организуешь на мисте темку, по сбору списков гуидов. Я могу такой сформировать по примерно 30 гиговой базе. Берешь выборку из 100ни баз, проводишь анализ, и находишь одинаковые. Считаешь вероятность. Сообщаешь всем.

всегда был. Не знаю, куда у вас подевался...

"Берешь выборку из 100ни баз, проводишь анализ, и находишь одинаковые." это надо центральную базу ГУИДов составлять, и расасылать обработки для сбора новых.

Короче, похоже, что 6 байт - тупо идентификатор базы. Т.е. пересечение уидов разных баз - маловероятно. Кроме уида базы и времени в тиках остаются 2 - 3 байта, которые х.з. как формируются. Это и не сессия и не вид документа.

Логично, т.к. наверняка базы создавались из одного шаблона типовой БП, где изначально была заведена "Наша организация".

ссылку или алгоритм , подтверждающие Ваше утверждение.

Гилев как-то говорил. А по теме -

вот еще на посошок

и еще на дорожку

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

+ и не было.

+ Проверяется тупым экспериментом за 2 минуты.

какой из двух: рарусовский или создатель видеокурсов ?

Случалось и не раз. Поэтому всячески избегаю обменов по ГУИДу.

С какой это пьяной радости. У меня вполне может быть ГУИЛ поступления совпадать с ГУИД реализации и счет-фактуры

GUID "уникальный", так как использует данные о времени выполнения и оборудовании компьютера, так как различий много, то есть некоторые гарантии уникальности. Но, когда вы переходите к работе с виртуальными машинами, то велика вероятность того, что две машины будут настролько похожи, что произойдёт генерация одинакового идентификатора. Проблема для 1С в том, что она генерит не 1 идентификатор, а сразу набор (так проще - команда генерации позволяет указать некоторое количество ID, которые будут отличаться только полем счётчика), а потом достаёт следующий ID из набора - так что, если совпадёт начальный ИД, то будет как в семёрке - два одинаковых набора. Правда, система никак не проверяет использование одинаковых ID для разных типов данных.

рарусовский конечно. Второй еще менее.