← На главную

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

В этой статье мы подробно разберем, почему возникает такое поведение платформы, как устроен механизм подписок на события при использовании определяемых типов и какие шаги необходимо предпринять для устранения неполадки.

Причины возникновения ошибки

Проанализируем архитектурную логику платформы «1С:Предприятие» и выясним, почему типовой неизмененный объект вызывает критическую ошибку метаданных:

1. Принцип пересечения доступных событий для определяемых типов. В типовых конфигурациях (в частности, в «1С:Бухгалтерии предприятия 3.0») источником подписки УстановитьПометкуУдаленияПрисоединенныхФайлов выступает ОпределяемыйТип.ВладелецПрисоединенныхФайловОбъект. Список доступных для подписки событий формируется динамически как логическое пересечение событий всех типов метаданных, входящих в определяемый тип. Если в состав типа по ошибке попадает объект, у которого отсутствует событие ПередЗаписью (например, ссылочный тип ДокументСсылка.* вместо ДокументОбъект.*, константа или регистр), платформа не может сопоставить общее событие для всего списка и поле «Событие» в свойствах подписки становится пустым.
2. Особенности ранних релизов платформы 8.3.10. В первых сборках ветки 8.3.10 механизм компиляции объединенной схемы метаданных (основная конфигурация плюс расширение) содержал ошибку строгого валидатора. Если конфигурация запускалась без расширений, платформа игнорировала «спящие» подписки с пустым событием. Однако при подключении расширения и особенно при модификации модулей объектов или команд включалась глубокая перепроверка всей структуры метаданных, включая неизмененные типовые объекты на замке, что приводило к сбою проверки.
3. Рассинхронизация режимов совместимости. Различие в значениях свойств режима совместимости у расширения и основной конфигурации часто провоцирует сбои компилятора метаданных на старых версиях платформы.
4. Нарушение целостности кэша и таблиц метаданных. Физическое удаление объектов из основной конфигурации параллельно с переносом их в расширение может приводить к рассинхронизации внутренних связей в таблицах Config и ConfigSave.

Способ 1. Синхронизация режимов совместимости конфигурации и расширения

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

Разберем по шагам порядок действий в конфигураторе:

1. Откроем свойства корневого узла основной конфигурации и проверим свойство «Режим совместимости». Установим его в значение Версия 8.3.9 (или в версию, соответствующую текущим требованиям релиза конфигурации).
2. Откроем список расширений через меню «Конфигурация» — «Расширения конфигурации».
3. Выделим наше расширение, откроем его палитру свойств и проверим два параметра: «Режим совместимости расширения» и «Режим совместимости».
4. Установим оба этих параметра в значение Версия 8.3.9, чтобы они строго совпадали со значением основной конфигурации.
5. Сохраним изменения в расширении и обновим конфигурацию базы данных.

Такая корректировка отключает избыточную строгую валидацию пустых событий в неизмененных объектах поставщика и позволяет запустить базу в режиме отладки.

Способ 2. Проверка состава определяемого типа (если конфигурация снята с замка)

Если конфигурация уже находится в режиме редактирования с сохранением поддержки, разберем, как восстановить корректный состав типов источника подписки:

1. Найдем в дереве метаданных объект ОпределяемыйТип.ВладелецПрисоединенныхФайловОбъект и откроем его свойства.
2. Нажмем кнопку выбора типов в свойстве «Тип».
3. Проанализируем весь список выбранных объектов. Убедимся, что там выбраны исключительно объектные типы (*Объект), поддерживающие запись. Ссылочные типы (*Ссылка) выбирать для данного определяемого типа категорически нельзя.
4. Если в тип были ошибочно добавлены неподходящие сущности, снимем с них флаги.
5. После корректировки откроем свойства подписки ПодпискаНаСобытие.УстановитьПометкуУдаленияПрисоединенныхФайлов. В выпадающем списке свойства «Событие» снова появится доступный пункт ПередЗаписью. Выберем его и сохраним конфигурацию.

Способ 3. Восстановление целостности информационной базы и очистка кэша

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

1. Очистим локальный кэш. Закроем все сеансы 1С и удалим содержимое каталогов временных файлов пользователя:

   %LocalAppData%\1C\1cv8\

   %AppData%\1C\1cv8\

2. Проверим целостность базы утилитой chdbfl.exe. Для файловых баз запустим утилиту chdbfl.exe (находится в каталоге bin установленной платформы 1С), выберем файл 1Cv8.1CD, установим флаг «Исправлять обнаруженные ошибки» и выполним проверку.
3. Запустим тестирование и исправление. В меню «Администрирование» конфигуратора выберем «Тестирование и исправление информационной базы». Установим флаги «Проверка логической целостности информационной базы» и «Реструктуризация таблиц информационной базы».
4. Пересоздадим файл базы через выгрузку. Выгрузим базу в файл .dt через меню «Администрирование» — «Выгрузить информационную базу», создадим новую пустую информационную базу и загрузим архив обратно. Это гарантированно перестроит служебные таблицы метаданных.

Рекомендации по разработке в расширениях

Чтобы избежать подобных коллизий при дальнейшей работе, придерживаемся следующих правил:

1. Не удаляем типовые объекты. Не следует физически удалять из основной конфигурации типовые отчеты, обработки и формы при выносе их функционала в расширение. Это ломает внутренние механизмы библиотеки стандартных подсистем (БСП). Корректный подход — отключать видимость объектов через подсистемы, права и функциональные опции, сохраняя исходные объекты на поддержке.
2. Своевременно обновляем платформу. В релизах платформы ветки 8.3.11 и старше логика валидации расширений была существенно переработана и стабилизирована, что исключает ложные ошибки проверки неиспользуемых подписок.