При активной разработке в среде 1С:Предприятие 8.3 программисты часто сталкиваются с необходимостью расширения функционала типовых конфигураций без изменения основной конфигурации. Одним из наиболее удобных инструментов для этого являются расширения. Однако работа с ними иногда преподносит неприятные сюрпризы в виде платформенных ошибок. Одной из таких проблем является ошибка: "В схеме базы данных нет таблицы с именем DataHistorySettingsExt", которая возникает при попытке обращения к новому регистру сведений, созданному непосредственно в расширении.
Проанализируем ситуацию: платформа 8.3.21 (и некоторые релизы 8.3.22) имеет внутренний дефект, связанный с механизмом "Истории данных" для объектов расширений. Давайте разберем по шагам, почему это происходит и как мы можем обойти это ограничение, чтобы продолжить разработку.
Прежде чем переходить к лечению, разберем природу заболевания. Таблица DataHistorySettingsExt является системной. Она отвечает за хранение настроек механизма "История данных" именно для тех объектов, которые были добавлены через расширения конфигурации. Когда мы создаем новый РегистрСведений в расширении, платформа при обновлении конфигурации базы данных должна инициализировать соответствующие записи в системных таблицах. Из-за бага (например, зафиксированного под номером 10237424), при определенных условиях (разные режимы совместимости, кэширование метаданных или специфический порядок обновления) эта таблица не создается или платформа "теряет" связь с ней.
В результате при попытке открыть форму регистра или обратиться к нему программно, сервер 1С посылает запрос к SQL-серверу (или файловой таблице), не находит нужную структуру и выбрасывает исключение. Рассмотрим наиболее эффективные способы решения этой проблемы.
Это самый быстрый и часто помогающий "костыль". Даже если вам не требуется отслеживать историю изменений в вашем регистре, включение этого свойства заставляет платформу пересмотреть структуру связанных системных таблиц. Разберем алгоритм действий:
РегистрСведений и откроем его палитру свойств.ИсторияДанных.Проанализируем настройки самого расширения. Одной из частых причин некорректного создания таблиц в БД является расхождение между режимом совместимости основной конфигурации и расширения. Посмотрим, как это проверить:
Откроем свойства расширения (правой кнопкой на корне расширения — "Свойства"). Убедимся, что значение в поле РежимСовместимости в точности совпадает со значением в основной конфигурации. Если в основной базе стоит "Не использовать", то и в расширении должно быть "Не использовать". Любое различие может привести к тому, что при генерации SQL-запросов платформа будет использовать разные стандарты именования или структуры системных таблиц, что и приводит к ошибке DataHistorySettingsExt.
Если стандартные методы не помогают, стоит прибегнуть к более глубокой проверке базы данных. Обычное "Тестирование и исправление" может не дать результата, если не выбраны правильные опции. Рассмотрим правильную последовательность:
В процессе реструктуризации платформа физически пересоздает таблицы в соответствии с текущим деревом метаданных. Это позволяет "подтянуть" отсутствующие системные таблицы расширений.
Иногда проблема кроется не в самой базе данных, а в локальных сеансах или кэше сервера. Рассмотрим комплексную очистку:
Сначала попробуем очистить локальный кэш пользователя. Для этого можно удалить базу из списка и добавить её заново или воспользоваться очисткой папок %AppData%\1C\1cv8 и %LocalAppData%\1C\1cv8. Однако при работе с расширениями важнее бывает серверный кэш.
Если у вас клиент-серверный вариант работы, рекомендуется:
snaccxt в каталоге описания информационной базы на сервере (это кэш расширений)./ЗапуститьОбновлениеИнформационнойБазы.Выясним еще одну интересную особенность: иногда при копировании объектов из основной конфигурации в расширение или между расширениями переносятся скрытые идентификаторы (UUID), которые могут конфликтовать. Если вы создавали регистр копированием, попробуйте следующий метод:
Удалим проблемный регистр из расширения совсем. Применим изменения (F7). Затем вручную, через кнопку "Добавить", создадим новый РегистрСведений, прописав все его измерения и ресурсы заново. Это гарантирует, что платформа воспримет его как абсолютно новый объект и инициирует создание всех необходимых системных структур с чистыми идентификаторами.
Как мы уже выяснили, данная проблема признана официальной ошибкой. В версиях 8.3.21 она проявляется наиболее часто. Проанализируем возможности обновления. Если ваш текущий релиз ниже чем 8.3.22.1923 или 8.3.23, настоятельно рекомендуем выполнить переход на более свежую сборку. В версиях ветки 8.3.23 и выше механизмы работы с историей данных в расширениях были значительно переработаны, и данная ошибка там практически не встречается.
Важный момент: если вы используете клиент-серверный вариант и не имеете возможности быстро обновить платформу, а все вышеперечисленные способы не помогли, некоторые администраторы баз данных прибегают к созданию пустой таблицы в SQL вручную. Однако мы категорически не рекомендуем этот метод, так как это прямое нарушение регламента эксплуатации 1С, которое может привести к невозможности дальнейшего обновления метаданных.
Подведем итог: чаще всего проблему удается решить включением свойства История данных или синхронизацией режимов совместимости. Используйте эти методы как наиболее безопасные и быстрые.