_InfoRg в 1С: что это за таблица и как её использовать

При просмотре базы данных 1С на уровне СУБД (MS SQL Server, PostgreSQL) администраторы встречают таблицы с техническими именами вида _InfoRg1234. Такие названия не выглядят понятными, и возникает закономерный вопрос: что в них хранится и можно ли с ними работать напрямую. Ответ простой: _InfoRg — это физическая таблица регистра сведений, одного из основных видов объектов метаданных 1С.

Цифровой суффикс после префикса — внутренний номер объекта, который платформа присваивает автоматически при создании регистра в конфигураторе. По номеру нельзя понять, какому именно регистру соответствует таблица: соответствие хранится в служебной таблице Params и определяется через структуру хранения базы данных.

Понимание устройства таблиц _InfoRg нужно в трёх практических ситуациях: диагностика проблем с данными, построение прямых SQL-запросов для аналитики и интеграция 1С с внешними системами на уровне базы. Во всех случаях важно знать структуру полей и границы безопасной работы.

Что такое регистр сведений и почему таблица называется _InfoRg

Регистр сведений — объект конфигурации 1С, предназначенный для хранения информации в разрезе заданных измерений. Классические примеры: курсы валют, цены номенклатуры, штрихкоды, адреса контрагентов. Каждая запись регистра — это набор значений измерений, ресурсов и реквизитов.

Платформа 1С при сохранении конфигурации создаёт в СУБД физические таблицы с префиксами по типу объекта. Для регистров сведений используется префикс _InfoRg (Information Register). Аналогично существуют _AccumRg (регистры накопления), _Document (документы), _Reference (справочники), _InfoRgSL и другие служебные варианты.

Структура таблицы _InfoRg: какие поля внутри

Колонки таблицы формируются из структуры регистра. Имена полей технические, но подчиняются стабильным правилам именования:

• _Period — дата записи, присутствует только у периодических регистров;
• _RecorderRRef — ссылка на документ-регистратор, если регистр подчинён регистратору;
• _FldNNNN — измерения, ресурсы и реквизиты регистра; соответствие номера поля конкретному реквизиту определяется через структуру хранения;
• _SimpleKey — служебный ключ у некоторых независимых регистров.

Ссылки на объекты (справочники, документы) хранятся как 16-байтовые двоичные значения, а не как привычные строковые GUID. Поэтому прямой вывод такого поля в SQL-запросе даёт нечитаемый результат — для соединения с таблицей справочника используется бинарное сравнение полей.

Как узнать, какому регистру соответствует таблица

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

Порядок действий: откройте конфигуратор, перейдите в меню «Администрирование» → «Функции для технического специалиста» → «Структура хранения базы данных». Найдите нужный регистр сведений — в таблице будут указаны имя физической таблицы и назначение каждой колонки _Fld.

1. 1
   Откройте конфигуратор под учётной записью с полными правами
2. 2
   Перейдите: Администрирование → Функции для технического специалиста
3. 3
   Выберите «Структура хранения базы данных»
4. 4
   Найдите регистр сведений по имени и зафиксируйте имя таблицы и маппинг полей
5. 5
   Сверьте номер таблицы с именем _InfoRg в СУБД

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

Отличия _InfoRg от похожих таблиц

В базе 1С встречается несколько похожих префиксов, и их путаница приводит к ошибкам в запросах. Ключевые различия удобно свести в таблицу.

Отдельного внимания заслуживают виртуальные таблицы регистров сведений — «СрезПоследних» и «СрезПервых». На уровне СУБД им не соответствует отдельная таблица: платформа строит их запросом к основной таблице _InfoRg с группировкой по измерениям и максимальной дате.

Безопасная работа с таблицей: что можно и что нельзя

Чтение данных из _InfoRg прямыми SQL-запросами — распространённая практика для аналитики, выгрузок и интеграций. При соблюдении аккуратности (запросы только на чтение, без блокировок) это не вредит базе. Для тяжёлых запросов имеет смысл использовать режим READ UNCOMMITTED или реплику базы, чтобы не мешать работе пользователей.

Прямая запись в таблицу — совсем другая история. Изменение или удаление строк через INSERT/UPDATE/DELETE обходит всю логику платформы: не срабатывают обработчики, не пересчитываются служебные итоги, нарушается согласованность с копиями данных в других таблицах. Результат — рассинхронизация, ошибки при проведении документов и потенциально неустранимое повреждение базы.

Типичные задачи и как их решать правильно

Найти запись с некорректным значением

Если в интерфейсе 1С видна ошибочная запись регистра, а исправить её штатно не получается, сначала найдите запись в _InfoRg по значениям измерений — это поможет понять источник. Исправление же выполняйте через обработку в 1С: запись набора записей с корректными данными или удаление через объектную модель.

Построить внешний отчёт по данным регистра

Для отчётов вне 1С подключайтесь к _InfoRg на чтение, соединяя поля ссылок с таблицами справочников по бинарным ключам. Учитывайте, что при обновлении конфигурации структура таблицы и нумерация полей могут измениться — запросы потребуют перепроверки.

Оценить размер и рост таблицы

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

Ограничения и когда лучше не лезть в СУБД

Прямая работа с таблицами оправдана, когда штатных средств не хватает: сложная аналитика, интеграция на уровне данных, диагностика повреждений. Для повседневных задач — просмотра записей, корректировки, выгрузок — всегда предпочтительнее интерфейс 1С, запросы на встроенном языке и стандартные отчёты.

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

Маршрут решения

Как выбрать действие

Нужно только посмотреть или проанализировать данныеИспользуйте SQL-запрос на чтение к _InfoRg, предварительно получив структуру хранения

Нужно исправить ошибочные записиРаботайте через платформу 1С: набор записей, обработки, консоль кода

Нужна регулярная интеграция с внешней системойИспользуйте штатные механизмы обмена или чтение из _InfoRg без записи

Структура базы повреждена или данные рассинхронизированыВосстановите резервную копию и выполните тестирование и исправление в конфигураторе

Частые вопросы

Чем _InfoRg отличается от _AccumRg?

_InfoRg хранит данные регистров сведений — произвольную информацию в разрезе измерений. _AccumRg — таблица регистров накопления, где каждая запись имеет вид движения (приход или расход) и всегда привязана к документу-регистратору. Логика использования и структура полей у них разные.

Можно ли по номеру таблицы понять, что это за регистр?

Нет, номер присваивается автоматически и не связан с именем объекта. Точное соответствие даёт только структура хранения базы данных в конфигураторе или функция ПолучитьСтруктуруХраненияБазыДанных.

Безопасно ли читать данные из _InfoRg напрямую?

Да, запросы только на чтение не вредят базе. Чтобы не создавать блокировки для пользователей, используйте режим чтения без блокировок или выполняйте тяжёлые запросы на копии базы.

Почему ссылки в таблице выглядят как непонятные байты?

Ссылки на объекты 1С хранятся в СУБД как 16-байтовые двоичные значения, а не как строковые GUID. Для соединения с таблицей справочника сравнивайте бинарные поля напрямую, без преобразования в строку.

Что будет, если удалить строки из _InfoRg через SQL?

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

Изменится ли структура таблицы после обновления конфигурации?

Может измениться: при добавлении или удалении реквизитов регистра платформа перестраивает таблицу и нумерацию полей. Прямые SQL-запросы после обновления конфигурации нужно проверять заново по актуальной структуре хранения.