При обновлении платформы 1С:Предприятие на релизы ветки 8.3.24 и выше многие администраторы и разработчики столкнулись с неприятной ошибкой SDBL, которая блокирует проведение документов или выполнение определенных запросов. Текст ошибки выглядит следующим образом: "Ошибка SDBL: Таблица или поле DimHash не содержится в разделе FROM".
В этой статье мы подробно разберем причины возникновения этой ошибки, выясним, что такое DimHash, почему откат платформы или восстановление бэкапа не всегда помогают сразу, и рассмотрим пошаговые методы устранения неисправности.
Прежде чем приступать к "лечению", давайте разберемся в анатомии проблемы. Поле DimHash — это служебное поле, которое платформа 1С создает в таблицах базы данных (на уровне SQL) для регистров накопления или сведений — для этой задачи есть инструмент для анализа физической структуры таблиц и индексов SQL.
Это поле содержит хэш-сумму значений измерений регистра. Оно используется для оптимизации поиска записей и соединений таблиц, особенно если измерения имеют составной тип данных или являются строками неограниченной длины. В новых версиях платформы (начиная с 8.3.24) были произведены изменения в оптимизаторе запросов и механизме работы с этими хэшами.
Ошибка возникает, когда транслятор запросов 1С генерирует SQL-запрос, предполагая, что поле DimHash доступно для использования (например, для соединения с таблицей расширения), но физически в структуре таблицы SQL или в контексте текущего запроса это поле отсутствует или недоступно. Чаще всего триггером является наличие Расширения конфигурации, которое взаимодействует с регистром, но его схема данных рассинхронизировалась с основной конфигурацией после обновления платформы.
Обычно ситуация развивается по следующему сценарию:
DimHash.В обсуждении проблемы мы выяснили, что ошибка часто локализуется в конкретном регистре.
Самая частая причина — "протухшая" схема данных в расширениях. Расширение может не содержать явных изменений регистра, но само его наличие и активность могут влиять на генерацию запросов.
Важно различать отключение и удаление расширения:
Алгоритм действий:
DimHash.Если удаление невозможно (слишком много данных в расширении), а процесс ручной актуализации сложен, можно применить инструмент для обновления расширения конфигурации, чтобы ускорить и облегчить эту процедуру.
Если проблема кроется в физическом отсутствии поля или индекса, нам нужно заставить платформу 1С пересоздать структуру таблицы регистра на уровне СУБД. Самый надежный способ сделать это точечно — изменить свойства индексирования.
Давайте выполним следующие шаги:
Движения.Записать()).Это действие ("передергивание" индекса) заставляет платформу пересчитать хэши и пересоздать служебные поля, включая DimHash, что устраняет расхождение между логической и физической структурой. Для поддержания здоровья базы на уровне СУБД также важны внешние инструменты (поможет диагностика системных ошибок 1С и анализ долгих запросов в СУБД): если вы используете PostgreSQL, может помочь генератор скрипта для индексации таблиц, а для администраторов Microsoft SQL Server критически важна правильная настройка регламентных операций для регулярного обслуживания индексов.
Иногда конфликт возникает из-за разницы в режимах совместимости основной конфигурации и расширения. Платформа 8.3.24 строит запросы иначе, чем старые версии.
Проанализируем настройки:
Если точечные меры не помогли, необходимо выполнить полное обслуживание базы. Обратите внимание, что простая проверка логической целостности здесь бесполезна. Нам нужна именно реструктуризация.
Запустите конфигуратор в монопольном режиме:
Внимание! Реструктуризация на больших базах может занять значительное время, так как происходит пересоздание таблиц СУБД.
Если вы разработчик и хотите точно понять, в какой момент происходит сбой, используйте отладку. Ошибка SDBL обычно вылетает на уровне платформы при попытке записи набора записей. Кроме того, проверить корректность работы запросов к базе можно через консоль запросов (мод от Dr.Zombi), которая поддерживает отладку временных таблиц и пакетных запросов — для этого подойдёт консоль запросов для отладки метаданных и анализа данных.
Пример кода, где может возникать ошибка:
// Пример проведения документа
Процедура ОбработкаПроведения(Отказ, Режим)
// ... подготовка данных ...
// Ошибка чаще всего возникает здесь, при записи движений
Движения.ВыпускПродукцииУслуг.Записать();
КонецПроцедуры
Если вы закомментируете запись движений по конкретному регистру и документ проведется без ошибок, значит, вы точно локализовали проблемную таблицу. Далее применяйте к ней Способ 2 (перестройка индексов).
В ходе обсуждения возник резонный вопрос: почему даже восстановление старого бэкапа и запуск на старой платформе могут приводить к ошибке?
Дело в том, что если вы развернули бэкап и хотя бы один раз запустили его под новой платформой (8.3.24+), платформа могла успеть обновить системные таблицы или начать фоновую реструктуризацию (особенно если включено отложенное обновление). После этого физическая структура SQL меняется (добавляются ожидания полей DimHash), и старая платформа уже не может корректно работать с этим "гибридом".
Поэтому, если вы решаете откатываться, необходимо:
Ошибка "Поле DimHash не содержится в разделе FROM" — это результат конфликта оптимизаций новой платформы и текущей структуры базы данных (чаще всего при наличии расширений).
Для исправления: