При активной разработке в среде 1С:Предприятие 8.3, особенно на релизах ветки 8.3.22, программисты часто сталкиваются с необъяснимыми на первый взгляд ошибками SDBL. Одной из наиболее коварных является ошибка: В схеме базы данных нет таблицы с именем DataHistorySettingsExt. Эта ситуация возникает при попытке добавить новый объект (например, справочник) в расширение или при открытии формы такого объекта в режиме "Предприятие".
В данной статье мы подробно разберем причины возникновения этой проблемы и рассмотрим несколько методов её решения — от простых манипуляций с настройками до радикального восстановления структуры базы данных.
Проанализируем ситуацию: почему платформа требует таблицу, которую сама же должна была создать? Таблица DataHistorySettingsExt является системной. Она отвечает за хранение настроек механизма "История данных" специально для объектов, добавленных через расширения. В версиях 8.3.21 и 8.3.22 разработчики платформы внесли существенные изменения в работу этого механизма.
Ошибка SDBL (Simple DataBase Layer) означает, что уровень доступа к данным платформы ожидает увидеть в SQL-структуре таблицу, описание которой есть в метаданных, но фактически в базе данных она отсутствует. Это происходит из-за сбоя в процессе реструктуризации при применении расширения. Платформа "забывает" создать служебные таблицы для версионирования, но при любом обращении к объекту расширения пытается к ним обратиться.
Первым делом попробуем самый быстрый и безболезненный способ. Иногда достаточно "подтолкнуть" платформу к обновлению схемы данных для конкретного объекта. Выполним следующие шаги:
История данных в значение "Использовать" (если он не стоит) или, наоборот, снимем его, если он был установлен.F7 для обновления конфигурации базы данных.F7).Этот метод заставляет механизм реструктуризации перепроверить наличие необходимых системных таблиц и может автоматически досоздать DataHistorySettingsExt.
Часто проблема с таблицей SDBL сопровождается ошибками при выполнении Тестирования и исправления (ТИИ). Например, может возникнуть ошибка: Тип не определен '3937114e-c06a-47c2-85e6-ed96c6a4d446'. Этот GUID напрямую связан с внутренними системными типами метаданных расширений.
Если ТИИ завершается аварийно на этапе пересчета итогов, воспользуемся следующим лайфхаком:
Перейдем в параметры информационной базы и установим количество заданий при пересчете итогов равным 1. В некоторых сборках платформы 8.3.22 параллельное выполнение этих операций вызывает конфликты блокировок и ошибки доступа к системным таблицам расширений. После выполнения этой настройки запустим ТИИ повторно только с флагом "Пересчет итогов".
Если стандартные методы и выгрузка/загрузка .dt не помогают (так как ошибка структуры может "переехать" вместе с файлом выгрузки), придется прибегнуть к более сложному, но гарантированному способу. Рассмотрим этот алгоритм подробно:
Суть метода заключается в том, чтобы заставить платформу полностью пересоздать схему таблиц основной базы, очистив её от "фантомных" ссылок на отсутствующие таблицы расширений.
.cf) из чистой типовой базы той же версии (например, из шаблона Комплексной автоматизации)..cf через Конфигурация - Загрузить конфигурацию из файла.
Внимание: это приведет к потере всех реквизитов и объектов, которые были добавлены в основную конфигурацию вручную (не через расширения).F7). Платформа удалит "лишние" колонки и таблицы, приведя структуру SQL к эталонному виду..cf) используем механизм Конвертации данных 2.0. Создадим правила обмена между "сломанной" копией базы и обновленной базой. Поскольку структуры почти идентичны (разница только в расположении объектов — в основной конфигурации или в расширении), сопоставление пройдет автоматически.Этот метод позволяет полностью избавиться от мусора в системных таблицах Config и ConfigCAS, где хранятся данные о расширениях.
Для системных администраторов и опытных разработчиков существует путь исправления через SQL Management Studio. Платформа хранит информацию о расширениях в таблицах ConfigCAS (текущие) и ConfigCASSave (сохраняемые). Если ошибка SDBL не дает даже открыть базу, можно попробовать полностью очистить расширения из базы:
-- ВНИМАНИЕ: Это удалит ВСЕ расширения из базы данных!
DELETE FROM dbo.ConfigCAS
DELETE FROM dbo.ConfigCASSave
После выполнения этих запросов необходимо очистить серверный кэш 1С и заново добавить расширение в базу через Конфигуратор. Это спровоцирует платформу на создание структуры таблиц "с нуля".
Проанализировав технологические журналы многих систем, специалисты 1С подтвердили, что данная ошибка является критическим дефектом определенных сборок (в частности, 8.3.22.1709). Рекомендуется обновить платформу до релизов не ниже 8.3.22.1921 или перейти на более стабильные ветки 8.3.23 или 8.3.24.
В новых версиях механизмы SDBL при работе с DataHistorySettingsExt были значительно доработаны, и автоматическое создание недостающих системных таблиц происходит более надежно при первом же обращении к метаданным расширения.
Если вы столкнулись с ошибкой DataHistorySettingsExt, не паникуйте. Проанализируем краткий план действий:
История данных в объекте расширения..cf и переносом данных через Универсальный обмен данными в формате XML.Помните, что работа с расширениями на уровне структуры БД — это сложный процесс, и наличие резервной копии перед любыми манипуляциями с конфигурацией является обязательным условием успеха.