Как откатить конфигурацию 1С после неудачного динамического обновления

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

Метод 1. Восстановление из резервной копии через файл конфигурации (CF)

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

1. Развертывание копии: Восстановите утренний бэкап базы данных на тестовом сервере или локально. Нам не нужны данные пользователей за день, нам нужен только каркас — файл конфигурации.
2. Выгрузка CF: Зайдем в конфигуратор восстановленной копии и выполним команду Конфигурация — Сохранить конфигурацию в файл.... Сохраним полученный .cf файл на диск.
3. Загрузка в рабочую базу: Теперь перейдем в конфигуратор рабочей базы. Чтобы исправить ситуацию, нам нужно снова выполнить сравнение/объединение или полную загрузку конфигурации. Рассмотрим вариант с динамическим возвратом:
   • Выполним Конфигурация — Сравнить, объединить с конфигурацией из файла....
   • Выберем наш «чистый» .cf файл.
   • После завершения объединения нажмем Обновить конфигурацию базы данных (F7).

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

Метод 2. Использование штатного механизма «История конфигурации»

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

Перейдем в меню Конфигурация — История конфигурации.... В открывшемся окне мы увидим список всех сохранений конфигурации с указанием времени и автора. Проанализируем список и найдем версию, которая предшествовала неудачному динамическому обновлению. Нажмем правую кнопку мыши на нужной версии и выберем пункт «Установить как основную конфигурацию». После этого останется только нажать F7 для применения изменений. Этот способ позволяет избежать манипуляций с бэкапами и SQL-таблицами.

Метод 3. Низкоуровневый откат через SQL (для продвинутых пользователей)

Иногда динамическое обновление проходит некорректно, и база переходит в состояние «демонического обновления». При этом конфигуратор может выдавать ошибки при попытке любого действия. В таком случае мы можем попробовать очистить таблицы конфигурации непосредственно в SQL-менеджере. Посмотрим на структуру таблиц 1С в MS SQL Server.

Основная конфигурация хранится в таблице Config, а временные изменения для динамического обновления — в ConfigSave. Если обновление «зависло», нам нужно удалить информацию о незавершенной транзакции обновления. Выполним следующий скрипт (предварительно обязательно сделайте бэкап всей базы SQL!):

-- Очищаем таблицу временной конфигурации
DELETE FROM configsave;

-- Удаляем записи-маркеры о незавершенном обновлении
DELETE FROM config WHERE FileName = 'commit';
DELETE FROM config WHERE FileName = 'dynamicCommit';
DELETE FROM config WHERE FileName = 'dbStruFinal';

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

Метод 4. Очистка кэша — обязательный этап после отката

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

1. Серверный кэш: На сервере приложений 1С необходимо остановить службу 1C:Enterprise 8.3 Server Agent и очистить содержимое папки snacc (находится внутри каталога кластера серверов).
2. Клиентский кэш: Самый простой способ для пользователей — удалить базу из списка в стартере 1С и добавить ее заново. При этом создастся новая папка кэша с уникальным идентификатором. Если пользователей много, можно использовать скрипты для удаления содержимого папок %LOCALAPPDATA%\1C\1cv8 и %APPDATA%\1C\1cv8.

Рекомендации по предотвращению проблемы

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

• Фоновое обновление конфигурации базы данных: В современных версиях платформы это отличная замена динамическому обновлению. Подготовка изменений происходит в фоновом режиме, пока пользователи работают, а финальная фиксация требует лишь кратковременной монопольной паузы (обычно на несколько секунд).
• Хранилище конфигурации: Всегда ведите разработку в хранилище. Это позволит вам мгновенно откатиться к любой предыдущей версии (Snapshot) программного кода, просто выполнив команду «Получить из хранилища» для нужной версии.
• Тестовый контур: Никогда не делайте сравнение/объединение сразу на рабочей базе. Сначала выполните его на копии, убедитесь в работоспособности и только потом выгружайте .cf для обновления основной базы.

Подведем итог: если динамическое обновление уже «сломало» работу, не паникуйте. Оптимальный путь — извлечение .cf из утренней копии и повторное накатывание. Если же база заблокирована ошибками обновления — используйте SQL-скрипты для очистки системных таблиц Config.