Всем добрый день,
1с7.7 sql. Проблема - ID таблицы _1SCONST. Как проще всего понять содержание этих идентификаторов?
К таблицам они отношения не имеют и 1Cv77.DDS бесполезен. Без md это возможно? Есть только SQL.

Заранее признателен за советы.

Скорее вопрос в OBJID. Неважно.

Старый 1С-ик 1211212Скорее вопрос в OBJID. Неважно.
OBJID - это и без md - это id который есть в других таблицах, а вот чтобы понять в какой таблице этот OBJID, надо смотреть на ID, причем стоит учесть что по странной прихоти 1С ID хранится в 10-м виде, а не в 36-ричном , как OBJID и ID в других таблицах
16-ричном? Спасибо за помощь.

Да вижу, спасибо

pailВ этой таблице хранятся:
- значения всех простых констант
- история значений всех периодических констант
- история значений всех периодических реквизитов справочников

Для идентификации любого из этих значений dd(s) недостаточно - нужно дерево метаданных из md
В общем ситуация такая, что md-шника мне пока не допроситься (все в отпуске) и хотелось бы обойтись без него.

pail
Кстати, учти, что длина значащего поля в этой таблице только 20 симв, и более длинные строчные значения надо из нескольких записей собирать
Спасибо за инфу. Периодические реквизиты справочника типа другой справочник, т.е. другие коды в VALUE - скорее всего это не актуально.

Получил md-шник.
Возникла пара вопросов, общеобразовательных так сказать:
1) Словарь (dd) содержит описание только непериодических реквизитов/полей. Например, справочник Сотрудники содержит множество периодических реквизитов. Таблицы SQL не связаны. Таким образом, вопрос - существует ли какой нибудь способ определения принадлежности поля периодическому рекизиту, кроме косвенного (т.е., FIELD(36) <-> ID(10) _1SCONST -> смотрим содержание в 1С и SQL -> FIELD)?
2) Хотелось бы добавить пользовательскую функцию в БД (FIELD(36) <-> ID(10)). Лучше этого не делать?

TIA.

Словарь - 1Cv77.DDS

Первый вопрос отпал - словарь устаревший. Есть поля для периодических реквизитов.

И словарь не устаревший... Похоже наличие поля в таблице определяется вводом данных в реквизит, а не наличием реквизита. Ладно.

pailв dds описана физическая схема данных - все поля. Периодические реквизиты хранятся в 1sconst - структура которого тоже честно описана в 1cv7.dds - но этого мало.
Тебе нужно извлечь логическую схему базы (дерево метаданных) из 1cv7.md
Разные реализации этой задачи встречались. Даже сам когда-то делал.
Наиболее завершенные разработки по этой теме - в http://www.1cpp.ru/
раздел MetaDataWork

Когда узнаешь ID объекта(реквизита) - останется преобразовать его десятичное представление в 36-ричное (над алфавитом 0123456789ABCD....XYZ
чтобы узнать какие значения ID и OBJID искать в 1sconst для выделения значений нужных полей
Спасибо. В общем - то вопрос уже снят - разобрался.

У меня просто осталась эта пара вопросов (на рост эрудиции):
1) Хотелось бы добавить пользовательскую функцию в БД (FIELD(36) <-> ID(10)). Лучше этого не делать?
2) В свойствах справочника вижу реквизит, а в таблице и в словаре не вижу поля. Соответстенно,
предполагаю что проблемы с БД нет и это просто внутрення оптимизация хранения данных (попросту в поле ничего не вводили, зачем его заводить)?

pailесли в метаданных поле есть, а в таблице нет - это не оптимизация. Это поле хранится в другой таблице. Периодические реквизиты - в 1sconst, строки неограниченной длины - в 1sblob
Нет, все поля по справочнику (по крайней мере сотрудники) хранятся в одной таблице - в т.ч. и периодические -, но потенциально интерсеный реквизит для отделов в таблице отсутствует, я и сделал вывод, что они его попросту не ведут. Тогда он и не нужен для выборки.

На мой взгляд, это должно быть только у периодических реквизитов. Если не вру конечно.