← На главную

Механизм расширений конфигурации в платформе 1С:Предприятие 8.3 позволяет добавлять собственные реквизиты, табличные части, справочники, документы и регистры сведений. Однако при работе с расширенными данными разработчики сталкиваются с риском их безвозвратной утраты, особенно при выполнении процедур обновления типовых конфигураций или изменении режимов совместимости. Разберем внутренние механизмы хранения данных расширений в СУБД, выясним причины сбоев при обновлении и рассмотрим практические способы безопасного сохранения информации.

Как платформа 1С хранит данные расширений в СУБД

Для понимания рисков потери данных проанализируем, как платформа организует структуры в базе данных:

1. Собственные объекты расширения: если в расширение добавляется новый справочник, документ или регистр сведений, платформа создает для него отдельную независимую таблицу в СУБД.
2. Добавленные реквизиты к типовым объектам: если мы добавляем реквизит в существующий типовой справочник или документ, платформа не меняет структуру исходной таблицы конфигурации поставщика. Вместо этого в базе данных создается отдельная вспомогательная таблица расширения, связанная с основной таблицей по ссылке или внутреннему идентификатору.
3. Физическое удаление и отключение: если расширение полностью удаляется из информационной базы, платформа выполняет команду удаления соответствующих таблиц на уровне СУБД (DROP TABLE). При этом все накопленные данные в добавленных реквизитах и объектах безвозвратно стираются. Простое отключение активности расширения (снятие признака активности) сохраняет таблицы в базе данных, но скрывает их от прикладного кода до момента повторной активации.

Почему возникают ошибки обновления типовых конфигураций с расширениями

Рассмотрим, почему при обновлении типовых решений (например, 1С:Бухгалтерия предприятия) обработка обновления может завершаться аварийно при наличии расширений с собственными данными:

1. Кэш метаданных в Библиотеке стандартных подсистем (БСП): в ранних версиях БСП алгоритмы послеобновленческой обработки данных перебирали объекты через коллекцию основной конфигурации и внутренний кэш метаданных. Объекты и реквизиты расширения не попадали в эти структуры или вызывали рассинхронизацию при проверке состава метаданных, из-за чего процедуры обновления завершались ошибкой.
2. Конфликт режима совместимости: использование собственных реквизитов и объектов в расширениях требует отключения или повышения режима совместимости конфигурации (начиная с 8.3.11). Если основная конфигурация находится в более низком режиме совместимости, искусственное снятие совместимости («Не использовать») может нарушить работу встроенного кода БСП.
3. Ошибки платформы при работе с виртуальными таблицами: в ранних релизах платформы (в частности, 8.3.11 до релиза 8.3.11.2924) наблюдались платформенные ошибки при обращении к виртуальным таблицам регистров сведений расширения через консоль запросов или СКД (ошибка 10186928).

Пошаговый алгоритм выгрузки и восстановления данных расширения перед обновлением

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

1. Выгрузка структуры метаданных: с помощью специализированной обработки (например, MD83Exp) выгружаем структуру расширенной конфигурации в файл формата XML.
2. Создание правил обмена: в конфигурации «Конвертация данных» формируем правила обмена исключительно для добавленных объектов и реквизитов (новые справочники, добавленные поля типовых справочников и документов, регистры сведений).
3. Выгрузка данных и фиксация статистики: перед выполнением обновления выгружаем данные по подготовленным правилам через обработку универсального обмена в формате XML. Обязательно сохраняем статистику выгруженных объектов (количество записей по каждому объекту).
4. Обновление конфигурации: отключаем расширение, выполняем штатное обновление основной конфигурации, производим запуск в режиме «Предприятие» и дожидаемся завершения всех процедур обновления данных БСП.
5. Подключение расширения: подключаем расширение обратно и проверяем его корректное применение к обновленной конфигурации.
6. Загрузка данных и сверка: загружаем ранее выгруженный XML-файл с данными расширения и сверяем статистику загруженных объектов с исходными показателями.

Альтернативные способы хранения кастомных данных без риска потери

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

1. Механизм «Дополнительные реквизиты и сведения»: использование штатного функционала БСП позволяет хранить дополнительные пользовательские поля в предопределенных табличных частях и регистрах типовой конфигурации. Эти данные не привязаны к структуре расширения и не удаляются при его отключении.
2. Сериализация в служебные реквизиты: хранение сложных структур в существующих строковых полях типовых объектов (в форматах JSON или XML), если по этим данным не требуется строить индексы и выполнять частый поиск в СУБД.
3. Внешние источники данных: перенос критически важных специфических структур в отдельную базу данных или внешнюю СУБД с подключением через механизмы внешних источников данных или HTTP-сервисов.