При обслуживании типовых конфигураций (таких как «Управление торговым предприятием», «Зарплата и управление персоналом» или «Бухгалтерия») часто возникает ситуация, когда база данных долгое время не обновлялась. У многих специалистов появляется искушение применить быстрый метод: обновить тестовую базу по цепочке релизов, сформировать из неё один итоговый файл конфигурации (.cf) и просто загрузить его в рабочую базу через меню «Загрузить конфигурацию из файла».
Рассмотрим, почему такой подход категорически недопустим, к каким критическим ошибкам и потере данных он приводит, и проанализируем правильную технологию обновления через пропущенные релизы.
Разберем внутренний механизм обновления типовых решений 1С. Каждое обновление конфигурации состоит из двух принципиально разных частей:
Проанализируем классический пример потери данных при попытке объединить несколько релизов в один .cf:
Представим, что в релизе №1 разработчик добавляет новый регистр сведений и обработчик, который переносит данные из старого справочника в этот регистр. В релизе №2 старый справочник окончательно удаляется за ненадобностью. Если последовательно накатывать релизы с запуском базы в режиме «1С:Предприятие», программа успеет заполнить новый регистр до того, как справочник будет удален.
Если же загрузить в рабочую базу итоговый .cf-файл (в котором справочник уже удален), платформа мгновенно затрет таблицу справочника на уровне СУБД при реструктуризации. Когда после этого вы запустите режим «1С:Предприятие», обработчики обновления попытаются прочитать данные из удаленного справочника и вернут ошибку либо записанный регистр окажется пустым. В результате информация будет безвозвратно утеряна.
Перед началом выполнения любых работ по обновлению пропущенных релизов проанализируем необходимые подготовительные шаги:
1. Резервное копирование
Создадим резервные копии информационной базы. Для файлового варианта требуется сделать копию файла 1Cv8.1CD при завершенных сеансах пользователей, а также выполнить выгрузку информационной базы (.dt). Для клиент-серверного варианта следует создать полный бэкап средствами СУБД (MS SQL Server или PostgreSQL).
2. Проверка требований к платформе
Каждый релиз конфигурации требует определенной минимальной версии платформы «1С:Предприятие». Перед началом работ сверимся с файлом описания поставки (readme.txt) для промежуточных и финального релизов. При необходимости обновим платформу до требуемой версии.
3. Проверка целостности базы данных
Выполним проверку целостности, чтобы исключить повреждения логической структуры. Для файловой базы запустим утилиту chdbfl.exe (находится в каталоге bin установленной платформы). После этого в режиме Конфигуратора запустим Тестирование и исправление информационной базы из меню Администрирование.
4. Очистка кэша
При значительных изменениях структуры метаданных локальный кэш программы может вызывать сбои в работе сервисных модулей. Очистим кэш перед началом процедуры обновлений.
Выясним правильный порядок действий при обновлении базы с большим отставанием по версиям.
Шаг 1. Построение матрицы обновлений
Совершенно не обязательно накатывать абсолютно каждый выпущенный релиз. На сайте поддержки пользователей 1С в таблице обновлений указано, с каких именно предыдущих версий допускается обновление на текущий релиз. Выстроим кратчайшую безопасную цепочку (например, переходы через 3–4 ключевых релиза вместо 15 промежуточных).
Шаг 2. Пошаговое накатывание конфигурации
Для каждого очередного релиза из составленной цепочки выполняем следующие действия в Конфигураторе:
.cfu) или файл конфигурации (.cf) первого промежуточного релиза.Шаг 3. Обязательный запуск в режиме «1С:Предприятие»
Категорически важно запускать программу в режим «1С:Предприятие» после установки каждого промежуточного релиза! При запуске под пользователем с полными правами автоматическая система выведет окно «Обновление программы» и выполнит все необходимые обработчики информационной базы.
Шаг 4. Контроль отложенных обработчиков (БСП)
В современных конфигурациях на базе Библиотеки Стандартных Подсистем (БСП) процедуры обработки данных разделены на оперативные и отложенные. Оперативные выполняются при первом входе, а отложенные запускаются фоновыми заданиями.
Откроем раздел Администрирование — Обслуживание — Результаты обновления программы и перейдем по ссылке Отложенные обработчики обновления. Необходимо дождаться завершения всех отложенных процедур, прежде чем переходить к накатыванию следующего релиза цепочки.
Если цепочка состоит из множества релизов, процесс можно частично автоматизировать через командную строку. Выполнение команды обновления и последующий запуск Предприятия можно описать следующим образом:
Параметры запуска Конфигуратора для пакетного обновления:
1cv8.exe DESIGNER /F "C:\Bases\TradeDB" /N "Administrator" /P "Password" /UpdateCfg "C:\Updates\1.0.1.2\1Cv8.cfu" /UpdateDBCfg
Параметры запуска Предприятия для отработки сервисных обработчиков:
1cv8.exe ENTERPRISE /F "C:\Bases\TradeDB" /N "Administrator" /P "Password" /C ВыполнитьОбновлениеИБ
Если база данных не обновлялась несколько лет (пропущено несколько десятков релизов), последовательное пошаговое обновление может занять дни или недели работы, а риск возникновения скрытых ошибок в данных существенно возрастает.
В таком случае рекомендуется проанализировать альтернативный вариант:
Данный подход позволяет раз и навсегда избавиться от устаревшего «мусора» в базе данных, оптимизировать размер СУБД и начать работу на актуальном релизе без накопленных ошибок прошлых лет.