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

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

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

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

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

Если у вас возникли проблемы с обменом, то для программиста это слабая отмазка, ищите проблему в другом месте

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

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

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

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

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

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

(10) именно причем. сделал четыре новых документа подряд, получил следующие номера:
b6dc1ccc-e472-11df-922d-001e33069798
b6dc1ccd-e472-11df-922d-001e33069798
b6dc1cce-e472-11df-922d-001e33069798
b6dc1ccf-e472-11df-922d-001e33069798
Хотя если честно это не сильно влияет на надежность метода, но факт остается фактом.
Ну и расчет "Посмотрите сколько в реестре Win GUID ключей" несколько неверен, ибо количество возможных комбинаций и вероятность коллизий это совсем различные понятия. Для краха данных достаточно одной малюсенькой коллизии :)

Однако это все теория. На практике вероятность коллизии все равно очень мала, и в 1С без того хватает причин для краха данных :) Хотя если бы 1С предусмотрела в обмене флаг "новый/измененный", то проблемы бы совсем не стоило бояться -просто при создании объекта который уже существует, надо было бы вызывать исключение и звать админа искать проблему.

ПЫСЫ: Кстати реально существует возможность образования разных данных с одинаковыми идентификаторами. При не очень толковых выгрузках/загрузках с помощью устаревших обработок можно поймать такие глюки. У меня такие реально есть в базе.
Пока не придумал как лечить. Жду конца года, когда буду делать "Матрица перезагрузка".

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

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

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

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

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

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

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

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

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

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

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

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

Само собой РС должен ходить по всем 29 базам.

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