Как формируется GUID? (Уникальность его в пределах разных баз) #513986

GUID сериализуется при обмене как довольно длинной строкой, но все-таки существуют опасения, как бы при обмене двух и более независимых баз не возникла ситуация когда в разных базах существуют РАЗНЫЕ элементы с одинаковым GUID. В данный момент рассматриваю ситуацию в которой одна база обменивается с 29 других баз которые никак между собой не связаны (в смысле это не РИБ и никто не является ни для кого родительским узлом).

опасения имеют основания

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

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

Скорее всего работает обмен, который синхронизирует по ГУИД и еще какой то механизм загрузки данных (загрузка из 7.7 например) с синхронизацией по коду/наименованию или еще чему то. Вот и возникает такой конфликт, обмен создает элемент и поначалу они одинаковые с одинаковым ГУИД, потом какая то загрузка по коду переписывает эти элементы на свои другие, получается что ГУИД один а элементы разные

Вероятность очень мала, настолько что ей можно пренебречь. В алгоритме формирования ГУИДа участвуют в том числе и MAC-адрес компа, и текущее сист.время, и счетчик тактов процессора. Выпадающие ГУИДы РАВНОМЕРНО заполняют пространство параметров.

Проблем пока нет, стараюсь такие проблемы оставлять на этапе проектирования :) В данный момент это 29 независимых РИБ из которых в главке информацию достают раздельно, распечатывают/сохраняют, и потом сбивают вручную в единые отчеты. Но каждая из этих 29 баз сама по себе не маленькая. У меня например это 65 узлов, все в ФАЙЛОВОМ режиме :) На некоторых узлах по 15 человек одновременно. Конечно у меня самая большая база из этих 29, но тем не менее утешение это слабое. Часть проблем я уже решил, (к примеру автообмен у меня значительно интелектуальнее типового), часть примерно знаю как решать, но пока не имею полномочий... но наверняка есть и такие о которых я еще не знаю :) Вот их бы хотелось сократить до минимума... ПЫСЫ: Я знаю, что файловый режим да еще и на 8.0 это мазохизм в моей ситуации, но пока еще этот вопрос не в моей компетенции... :)

топик стартер: оцените степень числа в GUID? Посчитайте вероятность от: 340 282 366 920 938 463 463 374 607 431 768 211 455 возможных вариантов. Надеюсь вопрос отпадет сам собой :)

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

GUID и в Африке GUID. 1С тут не при чем. Скорее всего указанные используется для чего-то другого, а не для данных. Посмотрите сколько в реестре Win GUID ключей. 38 степень покроет всё, что может вам в голову придуматься в любых количествах :)

именно причем. сделал четыре новых документа подряд, получил следующие номера: b6dc1ccc-e472-11df-922d-001e33069798 b6dc1ccd-e472-11df-922d-001e33069798 b6dc1cce-e472-11df-922d-001e33069798 b6dc1ccf-e472-11df-922d-001e33069798 Хотя если честно это не сильно влияет на надежность метода, но факт остается фактом. Ну и расчет "Посмотрите сколько в реестре Win GUID ключей" несколько неверен, ибо количество возможных комбинаций и вероятность коллизий это совсем различные понятия. Для краха данных достаточно одной малюсенькой коллизии :) Однако это все теория. На практике вероятность коллизии все равно очень мала, и в 1С без того хватает причин для краха данных :) Хотя если бы 1С предусмотрела в обмене флаг "новый/измененный", то проблемы бы совсем не стоило бояться -просто при создании объекта который уже существует, надо было бы вызывать исключение и звать админа искать проблему. ПЫСЫ: Кстати реально существует возможность образования разных данных с одинаковыми идентификаторами. При не очень толковых выгрузках/загрузках с помощью устаревших обработок можно поймать такие глюки. У меня такие реально есть в базе. Пока не придумал как лечить. Жду конца года, когда буду делать "Матрица перезагрузка".

простой пример "неуникальности" GUID : 28 база делалась ...когда-то давно... методом копирования 27-ой :). Удалили "лишние" и переименования "нужные" справочники, удалили все документы. вот тебе и "счастье"

проблема не стоит выеденного ийца.  потому что если вдруг даже что-то такое случится, то во-первых - при загрузке в центр, где уже есть объект с таким уидом произойдет ошибка - и ты сразу эту проблему локализуешь (а если уид назначится объекту другого типа/вида - то вообще не проблема) во-вторых понятно что в этом случае делать, как исправлять. Поэтому тема не относится к разделу в8 а относится к разделу "как страшно жить" или "посоветуйте надежного и недорого психолога".

Ну ошибку он не получит, у него просто обновятся данные

Если у него используется дата запрета редактирования, и документ с таким же УИДом был в прошлом, то по крайней мере получит сообщение что редактирование данных того периода запрещено. Если конечно не настолько интеллектуализировал обмен, что он не будет проверять дату запрета.

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

+ рекомендую учесть возможность ввода гуида руками

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

Префиксы к номеру относятся - это для людей. А сам 1С пользуется GUID. У GUID префиксов нет.

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

так я и думал... короче, вот вам рецепт.. он не вылечит паранойю, но существенно ее купирует. Заводите независимый РС с единственным измерением типа строка с длиной достаточной чтобы принять строку гуида. При начале работы системы берете какой-нить справочник и получеате ссылку нового для него получаете строку типа b6dc1ccc-e472-11df-922d-001e33069798 заменяете два последних символа в первой группе на "_" получаете "b6dc1c__-e472-11df-922d-001e33069798" ищите запись в этом РС подобную последней строке. Если находите - завершаете работу системы Само собой РС должен ходить по всем 29 базам.

Ну тем самым мы предполагаем что в рамках одного сеанса может быть заведено 256 объектов :)