Как найти таблицу 1С в базе данных SQL

Когда база 1С работает в клиент-серверном режиме, все данные хранятся в СУБД — Microsoft SQL Server, PostgreSQL, Oracle или IBM DB2. Платформа 1С создаёт физические таблицы с техническими именами вида _Document123 или _Reference45, которые не совпадают с названиями объектов метаданных в конфигураторе. Чтобы выполнить прямой SQL-запрос, проанализировать блокировки или оценить объём данных, нужно сначала понять, какая физическая таблица соответствует нужному документу или справочнику.

Есть несколько способов найти соответствие: служебные таблицы самой базы, функции языка запросов 1С, внешние обработки и системные представления СУБД. Выбор зависит от того, есть ли у вас доступ к конфигуратору, к серверу СУБД и насколько глубоко нужно разобраться — найти одну таблицу или построить полную карту соответствий.

Важно понимать: прямой доступ к таблицам SQL предназначен в первую очередь для чтения и диагностики. Любые изменения данных напрямую в СУБД нарушают лицензионное соглашение 1С и могут повредить целостность базы.

Как 1С хранит данные в SQL и почему имена таблиц нечитаемы

Платформа 1С не создаёт таблицы с именами «Справочник.Номенклатура» или «Документ.РеализацияТоваров». Вместо этого каждому объекту метаданных присваивается внутренний числовой идентификатор, а физическая таблица получает имя из префикса типа объекта и этого номера. Например, справочник может храниться в таблице _Reference45, документ — в _Document231, регистр накопления — в _AccumRg1024.

Префикс указывает на тип объекта. Основные префиксы: _Reference — справочники, _Document — документы, _DocumentJournal — журналы документов, _Enum — перечисления, _InfoRg — регистры сведений, _AccumRg — регистры накопления, _AccRg — регистры бухгалтерии, _Seq — последовательности документов, _Const — константы, _Params — параметры, _Users — пользователи информационной базы.

Табличные части документов и справочников хранятся в отдельных таблицах с суффиксом VT и номером, например _Document231_VT456. Итоги регистров накопления лежат в таблицах _AccumRgT и _AccumRgOpt. Это важно при поиске: если вам нужны строки табличной части, основная таблица документа их не содержит.

Способ 1. Получить структуру хранения через конфигуратор

Самый надёжный и официально поддерживаемый способ — встроенная функция платформы ПолучитьСтруктуруХраненияБазыДанных(). Она возвращает таблицу значений, где для каждого объекта метаданных указаны имя таблицы хранения, имена полей в SQL и их назначение. Номер версии платформы влияет только на детали формата, сам механизм стабилен.

Чтобы воспользоваться функцией, откройте в конфигураторе или в режиме предприятия любую внешнюю обработку или консоль кода и выполните примерно такой код:

СтруктураХранения = ПолучитьСтруктуруХраненияБазыДанных();
Для Каждого Строка Из СтруктураХранения Цикл
Если Строка.Метаданные = "Документ.РеализацияТоваровУслуг" Тогда
Сообщить(Строка.ИмяТаблицыХранения);
КонецЕсли;
КонецЦикла;

Результат можно выгрузить в табличный документ или XML и искать уже в нём. У функции есть параметр, позволяющий получить структуру в терминах СУБД, что удобно, когда нужно сразу видеть физические имена полей, а не только таблиц.

1. 1
   Откройте консоль кода или создайте внешнюю обработку в конфигураторе
2. 2
   Выполните ПолучитьСтруктуруХраненияБазыДанных() и сохраните результат в таблицу значений
3. 3
   Найдите нужный объект по колонке «Метаданные» и возьмите значение «ИмяТаблицыХранения»
4. 4
   Проверьте таблицу в СУБД запросом SELECT TOP 1 * FROM <имя таблицы>

Способ 2. Найти таблицу через служебные таблицы базы SQL

Если доступа к конфигуратору нет, но есть доступ к СУБД, соответствие объектов и таблиц можно извлечь из самой базы. Платформа хранит описание структуры в служебных таблицах, главные из которых — Params и Config.

В таблице Params есть запись, поле FileName которой содержит значение DBNames. Соответствующее двоичное данное хранит карту соответствий в формате файла 1CD. Простым SELECT её не прочитать — данные упакованы. На практике администраторы используют готовые SQL-скрипты или внешние обработки, которые распарсивают этот блок и выводят читаемую таблицу «объект метаданных — физическая таблица».

Упрощённый приём для SQL Server — поиск по системным представлениям. Если известен хотя бы номер таблицы (например, из текста ошибки блокировки), можно найти её и сопоставить с объектом через структуру хранения. Обратный путь — посмотреть все таблицы с нужным префиксом:

SELECT name, create_date
FROM sys.tables
WHERE name LIKE '_Document%'
ORDER BY name;

Этот запрос покажет все таблицы документов, но без привязки к метаданным. Для полной расшифровки всё равно потребуется структура хранения из конфигуратора или обработка, читающая DBNames.

Способ 3. Внешние обработки и консоль структуры хранения

Для регулярной работы удобнее всего специализированные внешние обработки — «структура хранения базы данных», «поиск таблиц SQL» и подобные. Они запускаются в режиме предприятия, используют ту же функцию платформы и показывают интерактивную таблицу: слева дерево метаданных, справа физические имена таблиц и полей.

Преимущество таких обработок — фильтрация и поиск по части имени. Например, можно ввести «Номенклатура» и сразу увидеть все связанные таблицы: сам справочник, его табличные части, регистры, где он измерение. Это быстрее, чем перебирать результат функции платформы вручную.

Для файловых баз (формат 1CD) существуют отдельные инструменты, читающие структуру напрямую из файла. Они полезны, когда база не открывается или нужно извлечь данные из повреждённого файла, но для клиент-серверных баз они не нужны — там всё доступно через СУБД.

Как найти поле (реквизит) внутри таблицы

Найти таблицу — половина задачи. Реквизиты объектов тоже получают технические имена: _Fld123, _Fld456 и так далее. Служебные поля имеют фиксированные имена: _IDRRef — ссылка (GUID объекта), _Number — номер документа, _Date_Time — дата, _Posted — признак проведения, _Version — версия данных.

Сопоставление реквизитов и полей даёт та же структура хранения: функция платформы и обработки показывают для каждого реквизита имя поля в SQL. Если вы работаете напрямую с СУБД, ориентируйтесь на типы данных: _IDRRef — это binary(16), даты — datetime2, строки — nvarchar с длиной, заданной в метаданных.

Ссылки в 1С хранятся как 16-байтные значения. При выборке из SQL они выглядят нечитаемо. Чтобы преобразовать их в привычный GUID, используют специальные функции преобразования порядка байтов — готовые варианты таких функций для SQL Server и PostgreSQL широко доступны в профессиональном сообществе.

SELECT t.name AS TableName, c.name AS ColumnName, ty.name AS DataType FROM sys.tables t JOIN sys.columns c ON c.object_id = t.object_id JOIN sys.types ty ON ty.user_type_id = c.user_type_id WHERE t.name = '_Document231' ORDER BY c.column_id;

Типичные ошибки и риски при работе с таблицами напрямую

Главный риск — попытка изменить данные напрямую в SQL. Платформа 1С кэширует метаданные, ведёт служебные регистры, контролирует итоги и последовательности. Прямой UPDATE или DELETE обходит всю эту логику: итоги регистров станут недостоверными, ссылки могут «побиться», а в момент записи возможны конфликты с работающими сеансами. Кроме того, модификация данных в обход платформы нарушает условия лицензионного соглашения и лишает поддержки.

Вторая частая ошибка — работать с боевой базой без копии. Даже тяжёлый SELECT без подходящих индексов может вызвать блокировки и остановить работу пользователей. Диагностические запросы лучше выполнять на копии базы или в часы минимальной нагрузки, а для чтения использовать подсказку WITH (NOLOCK) в SQL Server с пониманием, что данные могут быть «грязными».

Третья ошибка — искать данные не в той таблице. Например, обороты регистра накопления хранятся в таблице итогов, а не в основной таблице движений; табличные части — в отдельных VT-таблицах. Если запрос вернул неожиданно мало строк, проверьте, не нужна ли вам смежная таблица.

Как проверить, что таблица найдена правильно

После того как вы определили физическое имя таблицы, убедитесь, что это именно тот объект. Самый простой тест — сравнить количество строк: откройте список документов или справочника в 1С, посмотрите число элементов и сравните с результатом SELECT COUNT(*) из найденной таблицы. Для документов учитывайте помеченные на удаление: в SQL они тоже присутствуют, признак пометки хранится в поле _Marked.

Второй способ — точечная сверка. Возьмите в 1С конкретный документ с известным номером и датой, затем найдите его в таблице по полям _Number и _Date_Time. Если запись нашлась и реквизиты совпадают по смыслу, соответствие подтверждено.

FAQ