Возможно ли найти одинаковые внутренние идентификаторы в двух разных базах 1С #591006

При условии, что между этими базами не было обменов, т.е. эти ИД появились в базе просто при вводе пользователем независимо новых объектов в базах... Или все-таки вероятность стремится к нулю?

вероятность есть

*всегда

Просто ваяю перенос между уже работающими базами, соответственно встал вопрос можно или не желательно синхронизировать по внутренним идентификаторам...

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

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

Они не просто должны повторяться, но и повторятся в рамках одного вида, а не всей базы

практически невозможно, за 3 года в 5 базах не возникло ни разу )

речь про uid-ы

А я про что?

УИД живут в таблицы. Причем для каждого документа/справочника свой уид. Нельзя без вида по УИДу найти объект (ну только если перебором всех таблиц)

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

в уид в восьмерке включен вид метаданных, уид из 2х частей состоит.

внутренний ИД не содержит вида

можно даже в одной и той же базе найти. К примеру, в одной из типовых версикй типового обмена между УТ11 и БП20 из одного документа (кажется ПТУ) делалось 2: ПТУ и допрасходы. Так вот у обоих одинаковый идентификатор. Что приводило к ошибке при заполнении книги покупок

Книга покупок по внутренним кодам работает?

Для составных полей там по любому вид будет

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

Вероятность что у тебя образуется вагина от мутаций куда больше, чем в id попасть

Маловероятно. Но могли вносить руками

про какой объект в частности говоришь ?

Бред. Даже обосновывать не хочется.

Что именно бред, что не может быть номенклатуры и контрагента с одинаковым внутренним кодом?

или например документа поступления и с таким же кодом документ реализация?

Да, если это не сделано руками.

Стоп. Я лишь уточнил сабж. Т.е. берем разные 2 базы. База А и база Б, которые жили своей жизнью. Далее решили настроить обмен по внутренним идентификатору между базами. Соответственно был вопрос могут ли эти коду повторятся. Я лишь уточнил, что для обмена не важно что код номенклатуры в базе А точно такой же как и код у контрагента в базе Б (мы же можем допустить что 2 разных вида справочника в разных базах по какой то причине получили одинаковый код?) Для обмена и для 1С это все равно будут разные элементы, потому что идентификация идет по паре вид + уникальный идентификатор, а не только по внутренним идентификатору Ты же пишешь что это бред, и типа даже объяснять не буду P.S. для буквоедов в тексте под кодом имеется ввиду внутренний уникальный идентификатор, который без вида

Съехал. Из >> Отсюда вывод, уид уникальный должен быть в рамках вида, а не всей базы Это бред.

А по твоему для идентификации объекта внутренний уникальный идентификатор должен быть уникальный для всей базы?

При условии что этот идентификатор не содержит вид?

Или мы о разных вещах говорим, или кто-то заблуждается

я говорю об УникальномИндетификатре, а ты говоришь о Ссылке. И полностью с тобой согласен в части поиска объектов, но не в части (повторюсь) >> Отсюда вывод, уид уникальный ДОЛЖЕН БЫТЬ в рамках вида, а не всей базы

+ он ДОЛЖЕН БЫТЬ уникальным везде. Если не уникален - кто то накосячил.

Что есть УникальномИндетификатре? Я почему справшиваю, запустил у себя в базе (в БП) справочники.СтатьиЗатрат.СписаниеНДСНаРасходы.УникальныйИдентификатор вернуло 6a99979c-b822-417f-bc35-2df9f6d0af10 И где тут вид?

Вернет тоже 32 символа (если черточек не считать), без привязки к виду. Т.е. в терминах 1С УникальныйИдентификатор не привязан к виду, и программа вполне себя хорошо чувствует, когда УникальныйИдентификатор одинаковый у номенклатуры и контрагента

при этом не зная вида, кроме как перебором видов, нельзя найти что это за элемент с 6a99979c-b822-417f-bc35-2df9f6d0af10

Давеча писал - "Нет не решаемых задач - есть не рациональные решения".

А по теме?

Вероятность совпадения ГУИДов в двух независимых базах есть и она больше нуля. ИМХО, этого уже достаточно, чтобы НЕ использовать ГУИД как единственный ключ для сопоставления объектов в двух независимых базах.. Если особо интересно, вероятность эту можно посчитать.. грубо 16^32 вариантов ГУИДов, количество объектов в БД тоже примерно прикинуть можно.. Из практики, на моей прошлой работе был настроен обмен: не по ГУИДам (32 байта), а по части ГУИДа (то-ли 28 байт, то-ли 30 уже точно не помню). Пару лет все было нормально. А потом начались совпадения.

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

, - может представить из жизни пример совпавших ГУИДов, созданных 1С? - "настоящих", полноразмерных

Естественно не единсвенный, сначала по Гуиду, потом по полям поиска, хотя было бы здорово, если бы в КД была возможность сделать обратную последовательность - сначала по полям поиска, а потом по Гуидам...