Помощник динамического обновления

Описание проблемы

Все мы знаем, что динамическое обновление — зло. Но когда на тобой стоит особа, приближенная к императору, говорящая, что «Все пропало!» и без немедленного динамического обновления, включающего 105-ю по счету печатную форму какого-нибудь шибко важного документа фирма не может работать и практически теряет по миллиону в минуту в этот самый ответственный момент времени, то приходится соглашаться, понимая, что все можен закончиться довольно печально.

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

Решение проблемы

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

В обработке всего 2 кнопки — Бекап таблиц и Восстановить таблицы.

При бекапе таблица конфигурации базы данных Config копируется в Config_bak внутри той же базы данных. Старая версия Config_bak при этом удаляется.

После этого своеобразного бекапа можно делать динамическое обновление. В случае сбоя, жмете на 2-ю кнопку, которая скопирует текущую таблицу конфигурации базы данных Config в Config_err, после чего копирует таблицу Config_bak в Config. Сбойную таблицу Config_err вы сможете потом на досуге проанализировать.

При желании, все вышеперечисленные процедуры можно производить и с таблицей конфигуратора ConfigSave.

На всякий случай напоминаю, что данный метод действенен для 1С 8.1/8.2 работающей в базе MS SQL.

И самое главное: во избежании проблем для себя любимого, переложите ответственность за данное действие с себя, на того, кто требует это обновление, предварительно объяснив ему  все возможные последствия этого.