Обновление конфигураций 1С с большим количеством доработок — всегда непростая задача. Ситуация существенно усложняется, если конфигурация пропустила 19 ключевых релизов, а предыдущие изменения вносились точечным переносом объектов и фрагментов кода без сохранения истории поставщика. В этой статье разберем, как правильно подготовить базу к обновлению, избежать утери данных и оптимизировать процесс, чтобы не накатывать каждый релиз вручную по 19 раз.
Рассмотрим ключевые сложности, с которыми сталкиваются разработчики при обновлении баз с большим числом пропущенных релизов:
.cf файлом 1С может воспринять типовой объект как новый, а измененный — как подлежащий удалению. Это приведет к полной очистке данных в соответствующих таблицах СУБД при реструктуризации..cfu файлов на некорректную конфигурацию поставщика приводит к ошибкам несовместимости версий.Готовить 19 отдельных промежуточных файлов с доработками не требуется. Проанализируем наиболее эффективный алгоритм действий, который экономит время и гарантирует сохранность данных.
.cf файл именно того релиза, который фактически установлен в базе в данный момент. В Конфигураторе через меню Конфигурация -> Поддержка -> Настройка поддержки выполняем загрузку или объединение конфигурации поставщика без изменения основной базы данных..cf файл самого последнего (актуального) релиза. В отдельном Конфигураторе или копии переносим в него весь доработанный функционал, доработанные реквизиты, модули и формы.БиблиотекаОбновленияИнформационнойБазыПереопределяемый в функции ОбработчикиОбновления(), а также в процедурах модуля ОбновлениеИнформационнойБазы. Если данные в промежуточных релизах меняли структуру, эти процедуры необходимо запустить.Разберем последовательный план действий для переноса обновлений на продуктивную базу данных:
Шаг 1. Анализ изменений и реструктуризации
Перед накатыванием подготовленного .cf файла на рабочую базу проверяем состав новых и измененных реквизитов. Если добавлено много новых тяжелых реквизитов в крупные справочники или документы, реструктуризация таблиц на базе в несколько сотен гигабайт может занять длительное время. В таком случае новые реквизиты можно добавить в рабочую базу заранее техническим обновлением.
Шаг 2. Последовательный запуск процедур обновления данных
Для того чтобы корректно отработали все алгоритмы трансформации данных за 19 релизов, применяем один из двух подходов:
.cf файлы ключевых релизов и каждый раз запускаем базу в режиме «Предприятие» до завершения обработки ОбновлениеИнформационнойБазы.ВыполнитьОбновление(). Доработки при этом затираются, но данные в регистрах и справочниках приводятся к формату актуального релиза. На финальном этапе накатываем подготовленный .cf с доработками..cf файл со всеми доработками, а невыполненные обработчики за пропущенные релизы вызываем программно или путем коррекции версий подсистем в регистре сведений ВерсииПодсистем.Шаг 3. Контроль окна реструктуризации
После нажатия кнопки «Обновить конфигурацию базы данных» внимательно изучаем диалоговое окно «Реструктуризация таблиц базы данных». Если в списке действий присутствуют пункты «Удаление объекта» или «Удаление реквизита» для объектов, содержащих учетные данные, процедуру выполнять нельзя. Это сигнал о том, что сопоставление объектов выполнено некорректно.
Проанализируем технические средства, которые помогут избежать ошибок в процессе обновления:
1. Использование 64-разрядного Конфигуратора: Для предотвращения падения Конфигуратора по причине недостатка оперативной памяти при сравнении объёмных конфигураций уровня УПП или КА, используем исключительно 64-разрядный клиент платформы 1С:Предприятие (64-разрядный 1cv8.exe).
2. Резервное копирование на уровне СУБД: При работе с базами на MS SQL Server или PostgreSQL перед запуском тяжелой реструктуризации обязательно создаем дамп/бэкап средствами самой СУБД. Восстановление средствами платформы 1С при сбое реструктуризации может завершиться неудачей.
3. Флаг «Показывать дважды измененные объекты»: В окне сравнения и объединения конфигураций включаем данный флаг. Он помогает быстро отфильтровать объекты, которые были одновременно изменены и вендором в новых релизах, и программистом в вашей базе.