|
как получить idTref изнутри 1С8.1 (в языке)
|
|||
---|---|---|---|
#18+
Нужно при выгрузке данных в наружу фиксировать их источник в 1С (пока - файловых). Т.к. поставщик данных - это РегистрыБухии.Хозрасчетный, то решил однозначно фиксировать по тройке (recordertref, recorderrref, lineno) причем (пока) неважно, будут ли recordertref, recorderrref представлены строкой или иначе (битовой строкой). насколько я понял, recorderrref - это (с точночтью до преобразования в строку) Код: plaintext
т.е. строка типа "07e3c030-0d29-11dd-a892-000ffe138c1c" а вот что такое recordertref? по моим наблюдениям, это видимо(?) первая (из 2-х) уидо-видная часть строки Код: plaintext
вопросы: 1. Правильно ли я это высчитал? 2. есть ли иной способ получить эту подстроку кроме как выпарсивая ее из ЗначениеВСтрокуВнутр()? 3. что нужно провернуть со строкой, чтобы она больше походила на бинарное данное в базе 1С? (впоследствии собираюсь сливать данные не из файловых 8-рок - прямиком из соответствующих таблиц). И нет ли способов получить их в языке 1С попрямее, чем выдирая из объекта ссылочного типа, да еще с промежуточным преобразованием в строку/из строки? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.04.2008, 15:03 |
|
как получить idTref изнутри 1С8.1 (в языке)
|
|||
---|---|---|---|
#18+
recordertref - идентификатор типа регистратора recorderrref - собственно ссылка на регистратор lineno - номер строки в наборе записей регистра Для идентификации регистратора достаточно одного recorderrref , тем более что recordertref может и поменяться (при реструктуризации метаданных). Кстати lineno зависит от бизнес-логики и может использоваться только для обеспечения уникальности записи, не более. авторчто нужно провернуть со строкой, чтобы она больше походила на бинарное данное в базе 1С Тут наоборот, но принцип преобразования понятен ... |
|||
:
Нравится:
Не нравится:
|
|||
26.04.2008, 15:05 |
|
как получить idTref изнутри 1С8.1 (в языке)
|
|||
---|---|---|---|
#18+
guest11 recordertref - идентификатор типа регистратора recorderrref - собственно ссылка на регистратор lineno - номер строки в наборе записей регистра Для идентификации регистратора достаточно одного recorderrref гм. ну я например смотрю структуру данных регистра. так там наименьший уникальный индекс именно по полной 3-ке. Т.е. с моей т.з. ничем (кроме как может быть самим 1с-ом) уникальность в регистре именно по двойке (idref,lineno) не гарантирована. Т.е. это (закладываться на отсутствующее в базе, но подразумеваемое ограничение) не есть хорошо. guest11, тем более что recordertref может и поменяться (при реструктуризации метаданных). а вот это вообще плохо. Подразумевается, что в моей базе каждая запись должна знать, чем она порождена в бухии. (какой строкой регистра). Если после изменения структуры метаданных происходит апдейт всех уже прописанных строк регистра- это ни в какие ворота. Одна надежда - не такие же <.....> в разработчиках. Или такие? guest11Кстати lineno зависит от бизнес-логики и может использоваться только для обеспечения уникальности записи, не более.что мне и нужно guest11 авторчто нужно провернуть со строкой, чтобы она больше походила на бинарное данное в базе 1С Тут наоборот, но принцип преобразования понятен Это я смотрел. Но мне нужно в PostgreSQL. А во вторых там, в тексте ф-ии, каст идет: cast(@binaryUUID as uniqueidentifier) - он, простите, не пользует ли какой специфической ф-ии MSSQL? (т.е. насколько исчисляем получается алгоритм преобразования из текста по этой ссылке?). ... |
|||
:
Нравится:
Не нравится:
|
|||
28.04.2008, 11:49 |
|
как получить idTref изнутри 1С8.1 (в языке)
|
|||
---|---|---|---|
#18+
guest11 Тут наоборот, но принцип преобразования понятен вот поэкспериментировал имея данное в 1С и в пг. Пришлось еще и переставлять фрагменты в конце (что каст в уид в мсскл переставляет какие-то куски строки?) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26.
теперь осталось понять, как выдрать ifTref (пусть и преобразонутый) изнутри 1С, чтобы получить SELECT encode(_recordertref,'hex') .... '00000081' т.к. мои догадки насчет нахождения Трефа в строке кажется не проходят: Код: plaintext 1.
'{"#",3ae7ecdf-938e-49f2-907e-95e0c1bb3e72,129:a892000ffe138c1c11dd0d2907e3c030}','07e3c030-0d29-11dd-a892-000ffe138c1c' т.е. вторая часть ЗначениеВСтрокуВнутр это в чистом виде encode(idrref,'hex'), без перестановок. А вот куда делось 00000081 - не ясно. конечно, если уникальность (_recorderrref, _lineno) - подтрамвайно гарантируется, то может быть ее и не искать ? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.04.2008, 13:19 |
|
как получить idTref изнутри 1С8.1 (в языке)
|
|||
---|---|---|---|
#18+
81 преобразуйте в десятичный получите 129 ... |
|||
:
Нравится:
Не нравится:
|
|||
28.04.2008, 16:44 |
|
как получить idTref изнутри 1С8.1 (в языке)
|
|||
---|---|---|---|
#18+
а encode это базовая в PGsql? в MSSQL такого комфворта нет ... |
|||
:
Нравится:
Не нравится:
|
|||
28.04.2008, 16:47 |
|
как получить idTref изнутри 1С8.1 (в языке)
|
|||
---|---|---|---|
#18+
Ферзьа encode это базовая в PGsql? в MSSQL такого комфворта нетда encode/decode -стандартные ф-ии кодирования [де]кодирования байтовой строки в обычную. Есть 3 "моды". Я проверял все. В 'hex'-вой обнаружил все искомые символы. (А в "ЗначениеВСтрокуВнутр - даже и сам порядок) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
... |
|||
:
Нравится:
Не нравится:
|
|||
28.04.2008, 17:28 |
|
как получить idTref изнутри 1С8.1 (в языке)
|
|||
---|---|---|---|
#18+
Ферзь81 преобразуйте в десятичный получите 129Спасибо! Т.е. в строкеВнутренней таки зашит тип. Хотя и не там, где я полагал его искать. Уже понятнее. Осталось понять, а нужно ли вообще его (тип) вытягивать и фиксировать (если, как утверждается, ууид ссылки на регистратор с номером строки сами дадаут уникум сквозь всю базу , даже без учета ссылки на тип регистратора, который еще может и измениться). ... |
|||
:
Нравится:
Не нравится:
|
|||
28.04.2008, 17:33 |
|
как получить idTref изнутри 1С8.1 (в языке)
|
|||
---|---|---|---|
#18+
1chainik Ферзь81 преобразуйте в десятичный получите 129Спасибо! Т.е. в строкеВнутренней таки зашит тип. Хотя и не там, где я полагал его искать. Уже понятнее. Осталось понять, а нужно ли вообще его (тип) вытягивать и фиксировать (если, как утверждается, ууид ссылки на регистратор с номером строки сами дадаут уникум сквозь всю базу , даже без учета ссылки на тип регистратора, который еще может и измениться). Тут палка о 2 концах с одной строны ИД непонятно для чего уникальны в рамках все БД (расчитывается от времени создания сеанса). В другом случае в ID сами можете установить для объекта и в этом случае будут проверяться только текущий тип. Так что лучше брать по максимуму .. поменяется (81 на 82) только если вы впереди своего объекта в конфигураторе, запихните еще какой нибуть.. обычно добавляют снизу... ... |
|||
:
Нравится:
Не нравится:
|
|||
28.04.2008, 17:45 |
|
как получить idTref изнутри 1С8.1 (в языке)
|
|||
---|---|---|---|
#18+
Ферзьв этом случае будут проверяться только текущий тип.понял. т.е. ,вообще говоря, мне нужно будет, к примеру, ввести таблицу историй типов, и при вставке новых данных из 1С "перекодировать" по ней idTref в изначальные... табличку содержать в непрерывной актуальности.... ну или какое-нибудь равнозначное решение PS насчет Вашей подсказки с типом - нашел функцию от самой 1С (в поставке их базы) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
... |
|||
:
Нравится:
Не нравится:
|
|||
28.04.2008, 18:01 |
|
как получить idTref изнутри 1С8.1 (в языке)
|
|||
---|---|---|---|
#18+
guest11 recordertref может и поменяться (при реструктуризации метаданных).А сам объект-регистратор при этом сохранит свое именование (не алиас) в метаданных? - Т.е., если я заведу его наименование вместо recordertref (вернее, технически - буду строить табличку соответствия recordertref-ов объектных типов "реструктурированных" конфигураций опираясь на имя (полное, вида "Документы.ОперацияБух") - могу я твёрдо рассчитывать , что объектный тип, называемый некогда "Документы.ОперацияБух" так и останется "Документы.ОперацияБух"-ом, а не станет скажем объектным типом с именем "Документы.ОперацияБухгалтераРучная"? И что это абсолютно верно для всех (хотя бы регистраторских) типов? Или это тоже слишком сильное (т.е. неоправданное на практике) допущение? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2008, 11:05 |
|
|
start [/forum/topic.php?fid=28&msg=35284240&tid=1524782]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
76ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
others: | 328ms |
total: | 496ms |
0 / 0 |