При обновлении нетиповых конфигураций программисты часто используют схему подготовки эталонного файла .cf на копии базы с последующим переносом в рабочую среду. Однако нередко возникает ситуация, когда после успешной, казалось бы, загрузки файла, внесенные ранее исправления или новые объекты попросту исчезают. Давайте разберем, почему это происходит, проанализируем технические нюансы платформы и выработаем надежный алгоритм обновления, который исключит потерю данных.
Типичный процесс, который мы рассматриваем, выглядит так: создается копия рабочей базы, обновляется через .cfu, в ней исправляются ошибки, выгружается .cf, и этот файл загружается в рабочую базу через «Загрузить конфигурацию из файла». На первый взгляд, логика верна, но в ней заложены две критические точки отказа: метод «Загрузки» вместо «Объединения» и игнорирование состояния кэша платформы.
Рассмотрим подробнее механизм Загрузить конфигурацию из файла. Этот метод предназначен для полной замены структуры метаданных. Если в процессе подготовки эталонного файла (п. 3 вашего сценария) какой-то объект был удален и создан заново с тем же именем, платформа присвоит ему новый UUID (внутренний уникальный идентификатор). Для системы 1С справочник Номенклатура с одним идентификатором и справочник с тем же именем, но другим UUID — это два абсолютно разных объекта.
При использовании функции «Загрузить конфигурацию» в целевой базе старый объект (с его данными в SQL-таблицах) будет помечен на удаление, а новый — создан «с нуля». В итоге визуально объект есть, но данных в нем нет, или логика кода, завязанная на старые ссылки, перестает работать.
Решение: Вместо полной загрузки мы рекомендуем всегда использовать Конфигурация — Сравнить и объединить с конфигурацией из файла. Это позволит платформе сопоставить объекты по именам и идентификаторам более гибко.
Выясним причину, по которой изменения могут «пропадать» визуально, хотя в конфигураторе они присутствуют. Кэш 1С — это сложная система, состоящая из нескольких уровней:
%AppData%\1C\1Cv8\. Там лежат скомпилированные формы и модули. Если после обновления кэш не очищен, пользователь может видеть старую версию формы.reg_1541) хранятся снимки конфигураций. Часто именно здесь «застревают» старые версии программного кода.Проанализируем ситуацию: если вы обновили базу, но не перезапустили службу rphost или не очистили временные файлы, система может продолжать обращаться к старым данным. Рассмотрим пример процедуры очистки, которую полезно включить в регламент:
// Регламент очистки при обновлении:
1. Остановить службу "Agent 1C:Enterprise 8.3".
2. Перейти в каталог данных сервера (C:\Program Files\1cv8\srvinfo\reg_1541\).
3. Удалить содержимое папки snccntxt.
4. Удалить содержимое временных папок пользователя (Local/Roaming).
5. Запустить службу сервера.
Если в пункте 5 вашего сценария вы применяете изменения, когда в базе находятся пользователи, платформа может выполнить динамическое обновление. Это основной источник проблем с «пропавшими» доработками. При динамическом обновлении основная конфигурация обновляется, а конфигурация базы данных — лишь частично. Это создает рассинхронизацию, которая лечится только монопольным вытеснением всех пользователей и повторным обновлением.
Чтобы избежать описанных проблем, мы предлагаем следовать «промышленному» стандарту обновления доработанных баз. Посмотрим на этот процесс детально:
Разберем этот этап: мы берем актуальную копию базы, накатываем .cfu, правим код, проверяем работоспособность. На выходе получаем файл stage_release.cf. Важно убедиться, что в процессе правок мы не снимали объекты с поддержки без необходимости и не меняли их UUID.
Открываем рабочую базу в конфигураторе. Выбираем Конфигурация — Сравнить, объединить с конфигурацией из файла, указывая наш stage_release.cf.
Проанализируем окно сравнения:
Это критически важный момент, который многие упускают. После объединения конфигураций версия поставщика в рабочей базе может остаться старой. Чтобы это исправить, выполним следующие действия:
Конфигурация — Поддержка — Настройка поддержки.Обновить конфигурацию.Выбор файла и указываем тот же самый .cf или оригинальный дистрибутив новой версии.После объединения и настройки поддержки обязательно выполняем Обновить конфигурацию базы данных (F7). Крайне желательно делать это монопольно. Если система предлагает динамическое обновление — отказываемся, выгоняем пользователей и делаем полноценное обновление.
Обратите внимание, если ваши исправления из п. 3 были внесены в Расширения конфигурации, то выгрузка .cf их не подхватит! Расширения существуют отдельно от основной конфигурации. В этом случае нам необходимо выгрузить расширение в файл .cfe и загрузить его в рабочую базу отдельно через Конфигурация — Расширения конфигурации.
Подведем итог. Проблема «исчезновения» доработок чаще всего связана либо с некорректным методом загрузки метаданных (замена через Load вместо Merge), либо с поведением кэша сервера приложений 1С. Используя методику сравнения/объединения и контролируя очистку временных файлов, вы обеспечите стабильность процесса обновления даже на самых сложных и сильно измененных конфигурациях.