Имя: Пароль:
1C
1С v8
Получить ТипЗнч зная только Ref_Key
,
0 http_user777
 
08.07.19
17:14
Собственно, сабж.
Может кто-нибудь знает как без перебора всех типов метаданных получить тип значения Ref_Key (GUID)?
1 lodger
 
08.07.19
17:21
один из кусков УникальногоИдентификатора имеет отсылку к типу ссылки, но это грязная магия зашитая в платформу. нужно знать гуиды объектов метаданных конфигурации, вспомнить как составляетя гуид объекта. при этом никто не запрещает присвоить гуид с неправильной отсылкой типа, лишь бы уникальный был (в пределах базы).
хочешь заняться этим?
2 http_user777
 
08.07.19
17:23
(1) Не, спасибо, покопаю в сторону "один из кусков УникальногоИдентификатора имеет отсылку к типу ссылки"
3 Cyberhawk
 
08.07.19
17:25
(1) Ошибаешься: ни в каком УИДе (из скольки-то там видов, используемых в 1С) отсылка к типу (объекту МД) не содержится
4 seevkik
 
08.07.19
17:28
Всегда считал гуиды уникальными только в пределах одного типа, ну и считаю что (1) не верно как минимум из-за того что этот самый гуид можно ввести до записи документа
5 Вафель
 
08.07.19
17:28
(3) формально нет, то так гуиды последовательные, то подсказка есть
6 lodger
 
08.07.19
17:35
а этот, укурок или правду чешет?
http://catalog.mista.ru/public/635159/
ну и таки да, в самой последовательности нет пары бит отвечающих за номер таблицы.
7 palsergeich
 
08.07.19
18:05
(6) Правду
8 palsergeich
 
08.07.19
18:06
В общем случае определить тип по ГУИД - нельзя, видел решения, где намеренно в 2 таблицы создавались записи с идентичными ГУИД
9 Жан Пердежон
 
08.07.19
18:06
я так понимаю, у него случай с
<Объект не найден> (26:80f408002771598b11e7a3f0a3a64c3b)
и зная "26" хочет получить ТипЗнч();

я делал перебором;
10 palsergeich
 
08.07.19
18:06
Это совсем просто
11 palsergeich
 
08.07.19
18:07
ПолучитьСтруктуруХраненияБазыДанных()
Это 26 и будет номером таблицы
12 palsergeich
 
08.07.19
18:09
(11) ну _Ref26 - это будет искомая таблица точнее
13 http_user777
 
08.07.19
18:11
(9) Не, у меня http-сервис возвращает refKey документа, а он может быть трех типов.
14 Жан Пердежон
 
08.07.19
18:17
(11) так это ничуть не быстрее
15 palsergeich
 
08.07.19
18:19
(14) Это можно хранить расчитанным, ибо данные меняются только с реструктуризацией
16 palsergeich
 
08.07.19
18:20
(13) Ты можешь называть это как угодно.
Напиши что именно там.
Если просто уникальный идентификатор, то однозначно определить таблицу нельзя
17 Сияющий в темноте
 
08.07.19
19:20
Обьект не найден возвращает нн гуид,а текстовое представление ссылки,еще болен интересное представление дает ЗначениеВСтрокуВнутр,которая напишет и идентификатор типа.
записать одинаковые идентификаторы в разные таблицы никто не мешает,так как есть установить ссылку нового,но нужно понимать,что во многих местах идентификатор используется без привязке к таблице,особенно это важно для обменов.
18 bolero
 
08.07.19
19:25
(0) Если подозреваемые элементы - субъект какой-либо синхронизации, то есть вариант сначала смотреть в РС.ПубличныеИдентификаторыСинхронизируемыхОбъектов, а потом уже перебором. Но если у тебя перебор из трех возможных значений, а не трех тысяч - лучше уж сразу тогда перебором, быстрее будет.

И таки да, правильнее будет допилить (или попросить допилить) http-сервис.
19 Cyberhawk
 
09.07.19
09:37
(5) Непонятно, про какую ты подсказку. Если ты про среднюю часть УИДа (которая между штампом времени и МАС-адресом), то она вряд ли может являться подсказкой, т.к. пачка из 32 выдаваемых (упорядоченных, да) соединению УИДов может расходоваться на УИДы, получаемые через менеджеры разных типов объектов. Такие дела.
Выдавать глобальные идеи — это удовольствие; искать сволочные маленькие ошибки — вот настоящая работа. Фредерик Брукс-младший