Каждый разработчик 1С хотя бы раз в жизни сталкивался с ситуацией, когда в процессе редактирования метаданных случайно удалялся важный объект — будь то сложная обработка, отчет, документ или справочник. Ситуация усугубляется, если рефлекторно была нажата комбинация клавиш Ctrl+S (сохранение изменений). В этот момент кажется, что многочасовая работа безвозвратно утеряна.
Однако не стоит паниковать. Если вы еще не успели обновить конфигурацию базы данных (не нажимали клавишу F7 или соответствующую кнопку на панели инструментов), восстановить удаленный объект можно стандартными средствами платформы. В этой статье мы подробно разберем, как устроена система хранения конфигураций «под капотом» 1С, как безопасно вернуть удаленные данные и что делать в более сложных ситуациях.
Для того чтобы осознанно подходить к процессу восстановления, давайте сначала разберем внутреннюю архитектуру платформы 1С:Предприятие. В любой информационной базе одновременно сосуществуют как минимум две конфигурации:
Ctrl+S изменения сохраняются только в эту область. В терминах СУБД (например, MS SQL Server или PostgreSQL) эти данные хранятся в таблице ConfigSave.F7 или меню Конфигурация — Обновить конфигурацию базы данных). В СУБД эта конфигурация живет в таблице Config.Пока вы не запустили процесс обновления базы данных, ваша рабочая конфигурация остается нетронутой. Это дает нам стопроцентную возможность отменить любые ошибочные действия в «черновике».
Давайте обратим внимание на заголовок окна дерева метаданных в конфигураторе. Платформа 1С визуально подсказывает нам текущий статус изменений:
Ctrl+S). В этом состоянии достаточно просто закрыть конфигуратор без сохранения, и все вернется на свои места.Ctrl+S была нажата), но основная конфигурация отличается от конфигурации базы данных. Именно в этом состоянии функция отката активна и полностью безопасна для использования.Если вы случайно удалили объект метаданных (например, обработку ПечатьНакладных), сохранили изменения и видите индикатор <!>, выполните следующие шаги для восстановления:
Перед тем как совершать любые действия по откату конфигурации, хорошей практикой является сохранение текущего состояния разработки. Возможно, помимо случайно удаленного объекта, вы успели написать полезный код в других модулях, который не хотелось бы терять.
Для этого в меню конфигуратора выберите пункт Конфигурация — Сохранить конфигурацию в файл... и укажите имя файла (например, temp_draft.cf). В случае необходимости вы сможете позже сравнить и объединить его с восстановленной конфигурацией.
Перейдите в главное меню конфигуратора и выберите пункт Конфигурация — Конфигурация базы данных — Вернуться к конфигурации БД.
Платформа выдаст предупреждение о том, что все несохраненные в базу данных изменения будут потеряны, и основная конфигурация будет полностью замещена рабочей версией из базы данных. Соглашаемся с этим предупреждением.
После завершения процесса дерево метаданных обновится. Вы увидите, что случайно удаленный объект снова появился на своем прежнем месте со всеми модулями, формами и макетами. Значок <!> в заголовке окна конфигурации исчезнет, подтверждая, что основная и рабочая конфигурации теперь абсолютно идентичны.
К сожалению, не всегда процесс восстановления ограничивается нажатием одной кнопки. Рассмотрим ситуации, когда стандартный метод "Вернуться к конфигурации БД" не может быть применен напрямую.
Если разработка ведется коллективно с использованием Хранилища конфигурации, команда возврата к конфигурации базы данных будет заблокирована платформой. В этом случае алгоритм действий выглядит иначе:
historic_version.cf. После этого выполните сравнение и объединение вашей текущей конфигурации с сохраненным файлом, вернув только удаленный объект.Если вы удалили объект не в основной конфигурации, а внутри Расширения, стандартное меню конфигурации базы данных не поможет, так как расширения имеют собственный изолированный жизненный цикл.
Чтобы выполнить откат для расширения, выполните следующие действия:
Если вы успели обновить конфигурацию базы данных, то таблицы Config и ConfigSave синхронизировались. Объект физически удален отовсюду. Но даже здесь есть варианты решения:
vendor.cf. После этого запустите сравнение и объединение (Конфигурация — Сравнить, объединить с конфигурацией из файла...), выберите этот файл и отметьте галочкой только ваш удаленный объект..epf или .erf) из конфигуратора временной базы, а затем вставьте обратно в рабочую базу. Если это справочник или документ, выгрузите конфигурацию временной базы в файл .cf и перенесите объект через сравнение-объединение.Для разработчиков также может быть полезен следующий код, позволяющий программно проверить работоспособность внешней обработки или отчета после восстановления их структуры из резервной копии:
// Пример программного подключения и проверки восстановленной внешней обработки
ПутьКФайлу = "C:\Temp\ВосстановленнаяОбработка.epf";
ДвоичныеДанные = Новый ДвоичныеДанные(ПутьКФайлу);
АдресХранилища = ПоместитьВоВременноеХранилище(ДвоичныеДанные);
Попытка
ИмяОбработки = ВнешниеОбработки.Подключить(АдресХранилища, , Истина);
ОбработкаОбъект = ВнешниеОбработки.Создать(ИмяОбработки);
Сообщить("Обработка успешно подключена и инициализирована!");
Исключение
Сообщить("Ошибка при подключении обработки: " + ОписаниеОшибки(), СтатусСообщения.Важное);
КонецПопытки;
Давайте резюмируем простые правила, которые помогут свести к минимуму риск потери результатов вашей работы:
.cf. Это занимает несколько секунд, но гарантирует легкий откат без разворачивания тяжелых резервных копий СУБД.