Подскажите, БД 1С обеспечивает уникальность UUID, которой получаем посредством .УникальныйИдентификатор() в пределах всех БД или только в пределах объектов одного вида?

Допустим имеем 2 разных вида документов. У них UUIDы могут пересекаться или нет в 1 БД?

Да, могут.

Нет, не могут

Если имеется УникальеныйИдентификатор() коненчно.  ID в таблицах могут

*имеется в виду

Повторюсь: выражение, которое получено с помощью .УникальныйИдентификатор() будет гарантировано уникальным среди всех объектов различного вида/типа в пределах 1 БД?

(5)Да.

(6) спс

Допустим из БД №1 в БД №2 по ссылке (UUID) выгружается какой либо вид документов. Если в БД №2 создать вручную 1 документ этого вида, то его UUID может пересечься с одним из UUIDов документов, которые мы потом будет выгружать из БД №1?

(8) в теории не может пересечься, на практике и палка раз в год стреляет...
Таким образом практически все типовые обмены сделаны.

2(8) Если уид двух объектов одного вида будет одинаков, они "сольются" в базе приемнике.
То есть от объекта заведенного руками, после загрузки сообщения обмена не останется и следа... кроме разве фантома в ЖР в поле "Представление Данных"

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

(11) я как раз про этот шанш или
(8) палку

Сейчас делаю выгрузку для 1 завода из 1 бд в другую. Большого кол-ва видов документов. Причем некоторые виды документов 1 БД сливаются в 1 вид документов другой БД. Пока выгружаю по UUID. Вот думаю правильно ли это стратегически?

"Причем некоторые виды документов 1 БД сливаются в 1 вид документов другой БД" - надо полагать что НЕСКОЛЬКО видов документов одной БД в ОДИН вид другой... Итого ты опасаешься, нет ли УЖЕ сейчас в БД1 двух документов РАЗНОГО вида с ОДИНАКОВЫМ уидом.
Дык проверь.

Эта тема неоднократно обсуждалась применительно как к GUID от фирмы 1С, так и к GUID от MS SQL Server. Историю вопроса излагаю по памяти. Первоначально в MS SQL для формирования GUID использовался MAC адрес сетевой платы (заведомо уникальный для каждого компьютера) и случайное число, сгенерированное на основе системной даты и времени в долях секунды. Понятно, что такой подход давал практически 100% гарантию, что GUID никогда не повторится. Потом пошли разборки относительно того, что MAC адрес сетевой платы нельзя выкладывать куда попало из соображений конфидециальности. Фирма Microsoft изменило алгоритм формирования GUID и засекретило его. Вероятность совпадения в разных базах несколько увеличилась и такие случаи на больших базах время от времени возникают.
Фирма 1С алгоритм формирования GUID скрывала с самого начала. Можно предположить, что ситуация примерно как с GUID от фирмы Microsoft.
(12)Насколько знаю, так делают. Но при этом проверяют на наличие совпадений.

2(14)нет, дело с 1С в другом. в том что первоначальный УИД формируется при первом создании нового объекта в конкретном сеансе, и затем инкрементируется для всех последующих объектов созданных в данном сеансе.
Ну и да, возможно детальный алгоритм формирования изначального уида в сеансе не известен, известно только что зависит от аптайма среды, выполняющей сеанс

(13) сейчас точно нет, т.к. 2ая БД пустая. Но они же могут появиться в будущем. Когда во 2ой БД начнут вводить вручную документы

(14) 1С или Ms sql имею разные алгоритмы формирования uid. На форуме в аналогичных ветках обсуждалось

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

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

Так что ищите ошибку в другом месте, она так вероятнее

(14) "Фирма 1С алгоритм формирования GUID скрывала с самого начала"
В том-то и дело. И она явно использует не майкрософтовский алгоритм. 1С каким-то макаром присваивает идентификатор сессии пользователя (составляющая гуида) и в её рамках выдача гуидов идет последовательно. Соответственно, смело гарантировать уникальность хотя бы в пределах БД я бы поостерегся. Фиг его знает, как оно на самом деле.

+(17) аналогично... Ни раз не видел чтобы совпадали уиды

понятно, можно впредь такие ветки относить в лайф с пометкой "холивар"

(16) Да вряд ли они появятся в будущем. 1С тоже вряд ли изобретала велосипед и использует майкрософтовсий гуид. Вероятность 1 на триллионы. Совпасть могут уже после обменов (если таковым пользоваться).

(17) на практике легко, когда умельцы подключают два независимых сервера 1С к одной базе

(22) Сомневаюсь, требую эксперимента и отчета

(22) Ты с нумератором не путаешь?

Погорячился, контроль уникальности там не работает, uuid все равно разный создается