← На главную

При работе с расширениями в 1С:Предприятие 8.3 программисты часто сталкиваются с критической ошибкой: «Поле DimHash не содержится в разделе FROM». Эта проблема особенно характерна для отраслевых решений (например, от «Агрософт»), где используются сложные регистры накопления с большим количеством измерений. Ошибка возникает из-за рассинхронизации между описанием метаданных в конфигурации и фактической структурой таблиц в СУБД (SQL Server или PostgreSQL). Рассмотрим детально, почему это происходит и как исправить ситуацию несколькими способами.

Что такое поле DimHash и механизм его появления

Для начала проанализируем природу поля DimHash. Это техническое поле (Dimension Hash), которое платформа 1С автоматически создает в таблицах итогов регистров накопления и сведений. Оно невидимо в конфигураторе, но присутствует на уровне SQL-запросов. Платформа генерирует его в двух основных случаях:

1. Превышение лимита измерений: Если в регистре определено более 16 измерений. В этом случае 1С перестает индексировать каждое поле по отдельности и создает хэш-сумму всех измерений для оптимизации поиска и ускорения работы виртуальных таблиц.
2. Использование составных типов: Если в измерениях используются составные типы данных или определенные настройки индексирования, платформа может принудительно внедрить DimHash для повышения эффективности запросов.

Ошибка «Поле DimHash не содержится в разделе FROM» означает, что программный код (запрос к виртуальной таблице) ожидает наличия этого поля, но физически в таблице SQL оно отсутствует или не было создано при обновлении конфигурации.

Причина конфликта с расширениями

Выясним причину, почему это происходит именно при включении расширений. Когда мы добавляем или изменяем объекты через расширение, платформа должна перестроить структуру таблиц в базе данных. Однако механизм расширений иногда дает сбой: он сообщает платформе, что структура регистра изменилась и теперь требует использования DimHash, но фактическая команда ALTER TABLE для добавления колонки в SQL не выполняется или выполняется некорректно. Это часто связано с режимом совместимости конфигурации или багами конкретных релизов платформы.

Способ 1: Изменение типа измерений в расширении

Рассмотрим самое быстрое и практичное решение, которое помогло пользователям в реальной ситуации. Суть заключается в принудительной инициализации реструктуризации регистра через расширение.

Алгоритм действий:

1. Добавим регистр накопления (в нашем примере это ВыпускПродукцииУслуг) в расширение конфигурации.
2. Выберем одно или несколько измерений этого регистра.
3. Изменим их тип данных на составной тип (даже если фактически в этом нет необходимости для бизнес-логики). Например, к текущему типу добавим тип УдалениеОбъектов или любой другой ссылочный тип.
4. Обновим конфигурацию базы данных.

Этот маневр заставляет платформу полностью пересоздать структуру таблицы итогов в SQL. После обновления колонка _DimHash (или соответствующие индексы) создается корректно. Если ошибка пропала, можно попробовать вернуть типы данных назад, но часто стабильнее оставить составной тип в расширении.

Способ 2: Управление режимом «Разделение итогов»

Проанализируем ситуацию с таблицами итогов. Если у регистра включен признак «Разделять итоги», платформа создает дополнительные технические таблицы. Иногда расширение конфликтует с логикой обращения именно к этим таблицам.

Разберем шаги по исправлению:

1. В основной конфигурации (если она снята с замка) или через расширение временно отключим признак Разделять итоги у проблемного регистра.
2. Выполним обновление конфигурации базы данных (F7).
3. Снова включим признак Разделять итоги и повторно обновим базу.

Такая «перезагрузка» настроек часто инициирует полную пересборку SQL-индексов, что исправляет отсутствие поля в разделе FROM.

Способ 3: Глубокая реструктуризация через «Тестирование и исправление»

Если стандартное обновление через конфигуратор не помогает, воспользуемся инструментами обслуживания базы данных. Важно помнить, что обычная реструктуризация через динамическое обновление («демоническое обновление») только усугубляет проблему.

Порядок действий:

1. Обязательно создадим резервную копию базы данных.
2. Запустим режим «1С:Предприятие» в монопольном режиме.
3. Перейдем в Администрирование -> Тестирование и исправление.
4. Установим флаг только на пункте «Реструктуризация таблиц информационной базы».
5. Нажмем «Выполнить».

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

Способ 4: Очистка серверного кэша и метаданных

Иногда физическая структура в SQL верна, но сервер приложений 1С «запомнил» старую структуру и генерирует неверный SQL-запрос. Обычная очистка пользовательского кэша здесь не поможет.

Выполним следующие действия на сервере:

1. Остановим службу 1C:Enterprise 8.3 Server Agent.
2. Перейдем в каталог кластера серверов (обычно это C:\Program Files\1cv8\srvinfo\reg_1541\...).
3. Найдем и полностью удалим содержимое папок snccntx и config (внутри папки конкретной базы). Эти папки содержат кэш метаданных и сеансовых данных.
4. Запустим службу сервера 1С.

После этого платформа будет вынуждена заново считать структуру таблиц напрямую из SQL и построить верные планы запросов без обращения к несуществующим (или существующим только в кэше) полям DimHash.

Способ 5: Обновление платформы и режим совместимости

Нельзя забывать, что работа расширений с таблицами итогов — это сложный механизм, который активно дорабатывался фирмой «1С». В ветках платформы 8.3.15.х и 8.3.16.х официально признавались баги, связанные с генерацией DimHash в расширениях.

Проанализируем технические требования: если ваша база работает в режиме совместимости ниже 8.3.14, рекомендуется поднять режим совместимости (если это позволяет конфигурация) или обновить платформу до актуальных стабильных релизов (например, 8.3.22 и выше). В новых версиях логика перестроения индексов при использовании расширений значительно переработана и более устойчива к ошибкам структуры СУБД.

Заключение: Самым эффективным «человеческим» решением в данном случае является временное изменение типа измерения на составной в расширении, что принудительно исправляет структуру SQL-таблиц. Если же вы столкнулись с этой ошибкой в крупной базе, начните с очистки серверного кэша, так как это наименее инвазивный метод.