При работе с 1С на уровне системного администрирования или при написании прямых SQL-запросов разработчики часто сталкиваются с именами полей вида _Fld5106. Иногда возникает соблазн переименовать эти колонки в базе данных SQL для удобства или исправления ошибок соответствия. В этой статье мы подробно разберем, как платформа 1С связывает объекты метаданных с таблицами SQL, можно ли изменить эту связь и какие существуют безопасные альтернативы прямому вмешательству в структуру БД.
Для начала проанализируем ситуацию: где именно 1С хранит информацию о том, что реквизит "Основание" — это колонка _Fld5106? Платформа использует для этого специальные системные таблицы. Разберем два ключевых объекта:
params (или в таблице Config в зависимости от версии платформы и состояния базы). Она представляет собой «словарь» соответствий между GUID объектов метаданных и их физическими именами (префиксами _Fld, _InfoRg, _Document). Данные хранятся в виде текста, сжатого по алгоритму deflate.Config (или ConfigSave), которая содержит логическое описание всей структуры: типы данных, связи, индексы. Если вы измените DBNames, но оставите старые данные в DBSchema, при первой же реструктуризации платформа обнаружит несоответствие и попытается вернуть таблицу к «каноническому» виду, что может привести к потере данных или ошибкам загрузки конфигурации.Важный вывод: Прямое редактирование этих таблиц крайне опасно. Ошибка в одном байте при упаковке или распаковке deflate может привести к тому, что база перестанет открываться в конфигураторе с критической ошибкой структуры.
Рассмотрим попытку переименовать колонку в _Fld5106v2. Даже если нам удастся обновить записи в DBNames, мы столкнемся с жестким ограничением движка 1С. Платформа ожидает, что все имена полей соответствуют строгому шаблону: префикс _Fld + внутренний числовой идентификатор. Если парсер запросов 1С встретит суффикс v2, он не сможет корректно составить SQL-запрос SELECT, так как это имя не вписывается в алгоритм генерации кода платформы.
Произвольные имена допустимы только для внешних систем, которые обращаются к SQL напрямую, минуя сервер приложений 1С. Но для самой 1С такая колонка станет «невидимой» или вызовет ошибку обращения к СУБД.
Вместо того чтобы пытаться подстроить базу под свой код, давайте разберем правильный подход: подстройку кода под базу. Если ваши прямые SQL-запросы «ломаются» после обновления или переноса базы, когда имена колонок меняются (так называемое «плывущее» именование), необходимо использовать встроенный метод 1С ПолучитьСтруктуруХраненияБазыДанных().
Посмотрим на пример того, как программно получить актуальное имя колонки для реквизита документа:
// Получаем структуру хранения для конкретного документа
ТаблицаСтруктуры = ПолучитьСтруктуруХраненияБазыДанных("Документ.РеализацияТоваровУслуг");
// Ищем информацию о нужном реквизите
Для Каждого СтрокаТаблицы Из ТаблицаСтруктуры[0].Поля Цикл
Если СтрокаТаблицы.ИмяМетаданных = "Основание" Тогда
ИмяКолонкиВSQL = СтрокаТаблицы.ИмяПоляХранения;
Сообщить("Актуальное имя колонки: " + ИмяКолонкиВSQL);
КонецЕсли;
КонецЦикла;
Этот метод возвращает таблицу значений, в которой указаны все соответствия. Если вы пишете внешнее приложение (например, на C# или Python), рекомендуется перед выполнением основных задач запрашивать эти данные через COM-соединение или HTTP-сервис и кэшировать их. Это гарантирует, что ваш код не перестанет работать после очередной реструктуризации базы.
Если ваша задача — сделать SQL-структуру удобной для BI-систем или внешних отчетов, проанализируем вариант с использованием представлений (Views) или синонимов (Synonyms) прямо в MS SQL Server.
Мы можем создать представление, которое будет «переводить» системные имена в человекочитаемые:
CREATE VIEW v_SalesData AS
SELECT
_Fld5106 AS [Основание],
_Fld5107 AS [СуммаДокумента]
FROM
_Document150;
Однако помните о нюансе, упомянутом в обсуждении: при реструктуризации 1С часто пересоздает таблицы (создает временную, копирует данные, удаляет старую, переименовывает временную). В этот момент все связанные с таблицей представления и синонимы могут «отвалиться» или стать невалидными. Для решения этой проблемы опытные администраторы используют DDL-триггеры на уровне базы данных, которые автоматически восстанавливают связи после изменения таблиц.
Бывают ситуации (как в сообщении 10), когда 1С выдает ошибку о неуникальности имени колонки в SQL, хотя в самой СУБД всё выглядит корректно. Это явный признак рассинхронизации между Config и реальной физической структурой. Вместо ручной правки dbnames, выполните следующие шаги:
.cf, создать пустую базу и загрузить её туда. Если в пустой базе ошибка исчезла — значит, проблема была именно в системных таблицах сопоставления.Резюме: Прямое изменение связи реквизита и колонки через редактирование системных таблиц 1С технически возможно, но практически неоправданно из-за высокого риска повреждения базы. Используйте ПолучитьСтруктуруХраненияБазыДанных() для динамического определения имен и SQL Views для удобства внешнего доступа.