← На главную

При работе с механизмом расширений в платформе «1С:Предприятие 8.3» одним из самых острых вопросов является сохранность данных. Разработчики часто опасаются, что если расширение «отвалится» (не применится) после обновления основной конфигурации или из-за программной ошибки, то все накопленные в его реквизитах данные будут безвозвратно утеряны. В этой статье мы подробно разберем, как платформа управляет данными расширений, в каких случаях они удаляются на самом деле и как правильно переносить объекты из расширения в основную базу.

Механизм хранения данных расширений «под капотом»

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

Рассмотрим ситуацию, когда расширение не смогло запуститься. Это может произойти, например, если в основной конфигурации изменился тип данных реквизита, который заимствован в расширение. В этом случае расширение переходит в состояние «Ошибка применения». Важно понимать: данные при этом никуда не исчезают. Они остаются в таблицах SQL, но платформа временно блокирует доступ к ним, так как не может корректно построить модель метаданных.

Удаляются ли данные при отключении расширения?

Выясним разницу между «неактивным» расширением и его удалением. Платформа 1С придерживается консервативного подхода к защите данных:

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

Важный нюанс: для полного удаления расширения, которое создало свои структуры данных в БД, часто требуется монопольный режим. Это своеобразная «защита от дурака», предотвращающая случайную потерю информации в рабочем режиме.

Фоновая реструктуризация и монопольный режим

Проанализируем процесс внесения изменений. Начиная с версии платформы 8.3.14, механизм расширений поддерживает фоновую реструктуризацию. Это означает, что добавлять новые реквизиты и объекты в расширение можно даже тогда, когда в базе работают пользователи. Платформа создает новые таблицы в фоновом режиме и «подменяет» их незаметно для сеансов.

Однако, как отмечают эксперты, процесс удаления данных — это «аттракцион неслыханной щедрости», который почти всегда требует эксклюзивного доступа к базе данных. Это связано с тем, что платформе необходимо физически перестроить структуру таблиц SQL и очистить системные таблицы метаданных, что невозможно при активных транзакциях пользователей.

Возможные проблемы и «глюки» при сбоях

Несмотря на надежность хранения, работа с «неприменившимися» расширениями таит в себе определенные риски. Разберем основные из них:

• Блокировка записи: Если расширение расширяет существующий справочник своими реквизитами и оно не применилось, запись в этот справочник может стать недоступной или выдавать ошибки, так как платформа видит рассогласование между ожидаемой структурой объекта и реально существующей в БД.
• «Сиротские» таблицы: В редких случаях при некорректном удалении расширения (например, сбое сервера в момент реструктуризации) в SQL-базе могут остаться таблицы, которые уже не связаны ни с чем. Они занимают место и могут приводить к ошибкам при выполнении «Тестирования и исправления».
• Проблемы обновления: Если при обновлении конфигурации расширение конфликтует, администратор может в спешке удалить его, чтобы «база просто запустилась». В этот момент все данные, введенные пользователями в поля расширения, будут удалены навсегда.

Как перенести данные из расширения в основную конфигурацию?

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

Процедура выполняется в несколько шагов:

1. Создаем новый реквизит с аналогичным типом в основной конфигурации. Важно: имя может быть таким же, но для платформы это будет абсолютно новый объект.
2. Пишем обработку для переноса данных. Пример логики переноса:
   Скопировать код

   
   Выборка = Справочники.Номенклатура.Выбрать();
   Пока Выборка.Следующий() Цикл
       Объект = Выборка.ПолучитьОбъект();
       // Реквизит_Расширение - поле из расширения
       // Реквизит_Основной - новое поле в основной конфе
       Объект.Реквизит_Основной = Объект.Реквизит_Расширение;
       Объект.Записать();
   КонецЦикла;
   

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

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

Управление данными через технические функции

Для продвинутых администраторов в платформе предусмотрен инструмент «Управление данными расширений». Чтобы его найти, необходимо перейти в «Функции для технического специалиста» (ранее «Все функции»).

Этот инструмент позволяет проанализировать:

• Какие расширения занимают место в базе данных.
• Объем данных по каждому объекту метаданных внутри расширения.
• Позволяет принудительно очистить данные конкретного расширения, не удаляя само программное расширение (код).

Итоговые рекомендации

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

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