|
Какая вероятность совпадения внутреннего ИД элементов справочника? | ☑ | ||
---|---|---|---|---|
0
Kreont
04.01.12
✎
17:15
|
А то подозрение что совпали, может в 1С не совсем рандом алгоритм генерации :)
Есть одна база центр и две дочерние. (Обмен по организации) После взаимных обменов, в одной дочерней базе (справочник договоры) есть елемент, который привязан к той же дочерней базе, но код его видно что создан в другой. Как такое могло случиться? |
|||
1
andrewks
04.01.12
✎
17:16
|
а как, пардон, видно? по мак-адресу сравнивал?
|
|||
2
Aleksey
04.01.12
✎
17:17
|
А причем тут код?
|
|||
3
Aleksey
04.01.12
✎
17:18
|
А могло это случится например создали в дочки, в центре поменяли организацию в договоре, вот оно и ушло в другую дочку
|
|||
4
Kreont
04.01.12
✎
17:21
|
Ну код РИБ базы #1:ААА
Второй: БББ Как мог попасть (или кто мог создать елемент) в базе №1 с кодом: БББ0000130 и владелец организация с префиксом ААА. (3) Вроде исключено, центр только для анализа и сбора общей статистики по двух фирмах, используется только для чтения. Хотя по логах проверю сейчас, а то ж ручки шаловливые встречаются :) |
|||
5
andrewks
04.01.12
✎
17:21
|
код != внутренний ИД
|
|||
6
Kreont
04.01.12
✎
17:25
|
(5) за это в курсе, просто другого пока объяснение не вижу, из-за чего такой глюк может случиться: создаем в двух дочерних база елементы новые, и "случайно" у них генерится тот-же код гуид, после обмена и получается такой при(о)кол, и они склеиваются в один :(
|
|||
7
Aleksey
04.01.12
✎
17:26
|
Смотри по журналу регистрации где был создан и какой изначально был код
Если гуид "совпал" то в обоих дочках будет запись о создании. Также смотри автора (если кончено у тебя обмен идет под другим пользователем) |
|||
8
Torquader
04.01.12
✎
17:39
|
Никто не обещал, что GUID настолько уникальны, что не могут совпадать.
Предполагается, что это 16 байт какой-то информации, извлекаемой псевдослучайным образом на основе даты-времени и параметров машины - если все входные параметры совпали, то получаем одинаковые GIUD, хотя, все обещают, что такого быть не может. |
|||
9
vmv
04.01.12
✎
17:52
|
(0) не просто исчезающе мала, а безнадежно бесконечно мала - доказано уже - в архивах ищи и на других ресах.
Если гуиды совпали, то это проблема кода при обмене или заблуждение. Преобразуешь "подозрительные" гуиды в хмлстрока и сохраняещь или в отладчике копипастишь. потом в обеих базах проверяешь поиском ссылки по гуиду кто-же(какая ИБ) их породили. Если будет обнаружен дубль, то это обмен, хотя недавно писали и про бзики скуля, но это другая история |
|||
10
vmv
04.01.12
✎
17:56
|
(4) очень умный юзер мог создать, скопипастив гуид в буфер из одной базы и запустив в другой базе обработку в пару строк
ОбъектСсылка = Справочник.ТвойСправочник.ПолучитьСсылку(ЧужойГуидИзБуфера); Объект = Справочник.ТвойСправочник.СоздатьЭлемент(); Объект.УстановитьСсылку...(ОбъектСсылка) .... Объект.Записать(); |
|||
11
vmv
04.01.12
✎
17:57
|
+ что касается кода и префикса, то это еще проще
|
|||
12
Дядя Васька
04.01.12
✎
17:58
|
Вообще в семере этого избегали очень просто, часть внутренного ид содержала код базы в которой создан. В двух разных базах одинаковый не создашь никак. Неужели в v8 отказались от столь простого и надежного решения? ;)
|
|||
13
vmv
04.01.12
✎
17:58
|
(10) хотя хрен сработает)
|
|||
14
vmv
04.01.12
✎
17:59
|
(12) это и сейчас есть, только в самом гуиде скрыто поэтому и не сработает код в 10, я проверял как-то
|
|||
15
Дядя Васька
04.01.12
✎
18:01
|
(14) Ну не в гуиде, а перед ним. По сабжу просто изменили код, а уриб ориентируется на внутренний ид, только и всего.
|
|||
16
Дядя Васька
04.01.12
✎
18:02
|
+(15) Хотя тут что под названием GUID понимать конечно. Раньше это была часть ID, в терминологии v8 возможно весь ID GUID'ом обозвали.
|
|||
17
Aleksey
04.01.12
✎
18:18
|
(14) Нету сейчас этого
|
|||
18
Aleksey
04.01.12
✎
18:20
|
Не поверишь, у меня справочник контрагентов и номенклатуры выгружается из 7-ной базы со своим ГУИД, т.е. я могу загрузить в любую почку и он не задвоит справочники
А так да напрямую код в (10) может не сработать ибо представления и как оно там хранится - разной. 1С каверкает ГУИД |
|||
19
Aleksey
04.01.12
✎
18:22
|
GUID 1С-а представленный в 1С, например
Сообщить(Строка(Ссылка.УникальныйИдентификатор())); отличается от фактически хранимого в базе на некоторые перемешанные значения Например, в 1С он выглядит как 6F9619FF-8B86-D011-B42D-00CF4FC964FF В базе (фактически) он имеет значение: 6F9619FF-D011-8B86-B42D-00CF4FC964FF (Это тупо пример, там алгоритм перестановки другой, лень споминать) Важно! GUID 1С формирует не по правилам Microsoft, а инкрементно. В начале сеанса формируется стартовый GUID, к примеру 6F9619FF-8B86-D011-B42D-00CF4FC964F0 У каждого последующего, созданного в этом сеансе ссылочного объекта GUID будет на 1 больше, к примеру: 6F9619FF-8B86-D011-B42D-00CF4FC964F1 6F961A00-8B86-D011-B42D-00CF4FC964F1 6F961A01-8B86-D011-B42D-00CF4FC964F1 (c) v8: Где взять описание GUID, который в 1С 8? |
|||
20
Kreont
04.01.12
✎
18:48
|
(19) А вот это интересно, при таком инкрементном формировании, если чем подольше 1С не закрывать, вероятность совпадения тогда увеличивается
|
|||
21
Sammo
04.01.12
✎
18:58
|
Если не создавать гуид руками, то не совпадут.
Несмотря на псевдослучайность |
|||
22
sda553
04.01.12
✎
19:07
|
(0) Отвечу по порядку.
1. Вероятность очень низкая, но она есть. 2. У тебя скорее всего косяк с обменом и загрузками, и с этой вероятностью не связано. Уже не первый раз виду программиста который задается вопросом таким, всегда это при разборе оказывался косяк программиста, а не "вероятность" |
|||
23
Kashemir
04.01.12
✎
19:39
|
(10) Почему это не сработает ?
|
|||
24
echo77
04.01.12
✎
19:47
|
(0) Смотри журналы регистрации, версионирование и другие методы дознания - только журналы тебе помогут ответить на вопрос "какого хера так получилось?" и архивы баз можно поднять для этих же целей
|
|||
25
Torquader
04.01.12
✎
20:17
|
В стандартном GUID (CoCreateGuid) есть возможность генерировать некоторое конечное количество GUID с одной отметкой времени, и они действительно не сильно различаются - возможно, что именно этот алгоритм и использовали - то есть генерируют сразу какое-то большое количество GUID, а потом их просто используют, когда нужно - это проще, чем для каждого GUID вызывать алгоритм генерации, который на системном уровне требует синхронизации потоков, чтобы не было одинаковых GUID.
А переставлены они, скорей всего, из-за того, что используют unsigned long[4] вместо стандартной структуры GUID - там как раз два unsigned short местами переставятся. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |