Имя: Пароль:
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 выдаваемых (упорядоченных, да) соединению УИДов может расходоваться на УИДы, получаемые через менеджеры разных типов объектов. Такие дела.
Проблемы невозможно решaть нa том же уровне компетентности, нa котором они возникaют. Альберт Эйнштейн