Получить уникальный идентификатор 1с
Ну, собственно вопрос в теме..
Как получить УникальныйИдентификатор документа через COM соединение?
It-developer; cargobird; awp234; selmorn; lemilk; Slypower; user1188623; ivanek; cwant; Legavaz; байт; + 11 – Ответить
(12) посмотреть, какой тип у ВнешнийДОк и понять, что это не ДокументОбъект.
(12) Во-первых, метод УникальныйИдентификатор() есть у типа "ДокументСсылка" и отсутствует у типа "ДокументОбъект".
Во-вторых, при работе через COM строковые представления объектов базы-корреспондента и получать нужно на стороне базы-корреспондента.
It-developer; cargobird; awp234; selmorn; lemilk; Slypower; user1188623; ivanek; cwant; Legavaz; байт; + 11 – Ответить
(3) В данном случае - без разницы. XMLСтрока для УникальногоИдентификатора возвращает строковое представление уникального идентификатора. То же самое, вид сбоку.
(1) посмотрите мою обработку - там все эти функции есть.
(6) Давайте сравнивать одинаковые вещи, как у меня на картинке. Согласен, что сериализация XMLСтрока(КомСтр.Регистратор) происходит намного быстрее, чем XMLСтрока(КомСтр.Регистратор.УникальныйИдентификатор()) или String(КомСтр.Регистратор.УникальныйИдентификатор()) . Очевидно, значительное время тратится на выполнение метода УникальныйИдентификатор().
Плюс XMLСтрока - это сериализация по установленным правилам, а Строка() - просто строковое представление. Хоть на практике этот момент и не играет роли, но завязывать алгоритмы на представления - непрофессионально. Прецеденты их изменений между версиями 1С уже были.
Сейчас проверил - XMLСтрока(КомСтр.Регистратор) будет правильным ответом, ибо возвращается то же строковое представление уникального идентификатора.
Не работает, ничего не понимаю((
Делаю так:
ВнешнийДОк= ВНешБаза.Документы.МойДокумент.НайтиПоНомеру().ПолучитьОбъект();
УИ = Строка(ВнешнийДОк.УникальныйИдентификатор());//по итогу болт..ничего нет
(12) посмотреть, какой тип у ВнешнийДОк и понять, что это не ДокументОбъект.
(12) Во-первых, метод УникальныйИдентификатор() есть у типа "ДокументСсылка" и отсутствует у типа "ДокументОбъект".
Во-вторых, при работе через COM строковые представления объектов базы-корреспондента и получать нужно на стороне базы-корреспондента.
Почему нельзя упорядочить по ссылке, если в ней содержится дата создания?
Как уже было описано, guid изначально был придуман для РАСПРЕДЕЛЕННЫХ систем, в которых ПРОБЛЕМА УНИКАЛЬНОСТИ идентификаторов решена полным ОТКАЗОМ ОТ АВТОИНКРЕМЕНТА в пользу СЛУЧАЙНЫХ чисел и специальных техник. GUIDы случайны и неповторяемы по определению и в этом его достоинство и недостаток. Например, в предопределенных элементах и произвольных идентификаторах используется Random GUIDs (Version 4). В "типизированных" же Time-Based GUIDs (Version 1).
Можно ли вытащить время из гуида?
Можно. Но не нужно.
bdb62d89-cede-11e4-b12b-d4ae52b5e909
Алгоритм:
дата содержится в первых символах, bdb62d89-cede-11e4 которые нужно переставить задом наперед: 11e4-cede-bdb62d89
первый символ отбрасываем, убираем "лишние" знаки "-"(тире)
интервал в десятых долях микросекунд (HEX) получается равным: интервал16= 1E4CEDEBDB62D89
переводим его в десяничный интервал интервал10 = HexToDec(интервал16);
в результате получаем: интервал10 = 136 461 344 788 852 105
находим интервал в секундах: интервалСек = интервал10 / 10 000 000;
Делаем сдвиг даты от [3]
Почему части времени идут "задом-наперед"?
"Так сложилось" ;)
Например потому что guid'ы появились задолго до того, как до них добрались руки ietf и баз данных.
Или потому что платформа написана на C, а не на Java, а как мы знаем из асемблера архитектура x86 имеет little-endian byte order.
Или, как говорит википедия, использовалось 2 варианта: для передачи по сети "on-wire" "network" (big-endian) byte order, а для хранения "native" (little-endian) byte order.
В любом случая я не знаю как там было и можно только догадываться.
[2] [3]
Если отчет из одной конфигурации копипастой тащу в другую - ID сохранится его?(в моей его не было) (c) 2michael
Ответ: При копировании объекта из одной конфы в другую _копипастом_ внутренний гуид меняется!
НО: при сравнении объединении этого не видно!, так как происходит сопоставление по имени.
НО: это не касается и предопределённых данных! Если добавлять их вручную, а потом конфу разработки сравнить-объединить с боевой - возникнут дубли в справочнике!
В edt же есть режим сравнения только по guid.
При замене отчета в дереве конфигурации командой "Заменить на внешнюю обработку, отчет. " меняется ли внутренний идентификатор объекта (отчета)? (с) Pandoch upd:02.07.20
Ответ: Нет, гуид при замене из файла остаётся прежним
Другая вариация вопроса: Есть две разные конфы. Но в них есть одинаковый объект метаданных например документ "Покупка". Как можно получить внутренний идентификатор этого объекта в обеих базах, используемый в сравнении и объединении, чтобы удостовериться, что этот объект, не зависимо от имени, замениться, а не дублируется ? Как я понял ЗначениеВСтрокуВнутр() дает не тот ID который нужен мне.
При каждой выгрузке во внешний отчет/обработку guid генерируется заного. При загрузке из файла - востанавливается. Это позволяет хоть 10 раз выгрузить отчет/обработу во внешний файл, и каждый из этих файлов можно будет открыть параллельно в клиенте.
ЗначениеВСтрокуВнутр() выдает идентификатор прикладного типа, а не внутреннего объекта метаданных. Помимо внутреннего идентификатора у каждого объекта метаданных есть идентификаторы типов. Например ОтчетМенеджер.<Имя отчета> и ОтчетОбъект.<ИмяОтчета>:
Все типы имеют свои идентификаторы, но при загрузке через "Заменить на внешнюю обработку, отчет. " они, так же как и идентификатор метаданных, заменяются на текущие.
Например - загрузка в отчет ABCАнализПокупателей внешнего отчета ДебиторскаяЗадолжность.epf вызовет лишь добавление суффикса (такой отчет уже есть в конфигурации), а все идентификаторы остаются прежними.
Скрин до загрузки - после загрузки:
Идентификаторы не изменились.
Почему используется "перевернутый" формат UUID внутри 1с?
<Объект не найден> (26:80f408002771598b11e7a3f0a3a64c3b)
Не знаю. Знаю только что первая цифра соответствует имени таблицы в sql: Reference26 -> ВидыНоменклатуры
[1]
Есть же спецификация?
Есть.
Расшифровываю:
Timestamp - это 60-битное число, содержащее количество 100-наносекундных интервалов с 15 октября 1582 г.
Часть low обнуляется каждые 2^32 / 10^7 / 60
7 минут, часть mid через 1 год, часть hi сами представляете.
Version - старшие 4 бита в седьмом октете, содержат тип гуида.
0x0001 1 time-based version
0x0010 2 DCE Security version (POSIX UIDs)
0x0011 3 name-based version (MD5 hashing)
0x0100 4 randomly generated version
0x0101 5 name-based version (SHA-1 hashing)
Clock Sequence - используется чтобы избежать появления дубликатов, когда часы переводятся назад или меняется идентификатор узла. Если предыдущее значение счетчика известно - то увеличивается на единицу, иначе берется случайное число.
Node - содержит физический MAC-адрес сервера. Дада, проверьте ipconfig /all ;)
Примеры? Есть их у меня.
Мы же "программисты", накодим функции:
Проверим ссылку обычного документа:
Проверим ссылку, сформированную вручную:
Проверим работу счетчика "уникальности":
Можно даже так:
Какой мак-адрес у меня, вы уже знаете ;)
ps: под "упорядочить по ссылке" везде имеется ввиду сортировка в порядке создания ссылок и вообще в каком-либо порядке, отличном от сравнения в побитовом бинарном формате хранения бд.
Ну вот и все.
Надеюсь, теперь мысль о том, чтобы "упорядочить по ссылке", я из вас вытряхнул окончательно.
Читайте также: