Почему при последовательном обновлении 1С конфигурация поставщика отстает или откатывается назад?

При выполнении длинной цепочки обновлений типовой конфигурации (например, при переходе через 10–15 релизов подряд) разработчики нередко сталкиваются со странным поведением платформы: основная конфигурация успешно получает новый номер версии, а конфигурация поставщика в окне настройки поддержки застревает на предыдущем релизе или вовсе «прыгает» назад после запуска программы в пользовательском режиме. В результате при попытке установить следующий файл обновления (.cfu) система сообщает, что файл не предназначен для текущей конфигурации, либо возникает путаница с дважды примененными объектами.

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

Почему возникает рассинхронизация конфигураций

Чтобы понять природу ошибки, проанализируем, как платформа хранит метаданные в информационной базе:

1. Разделение таблиц Config и ConfigSave. Конфигурация поставщика, правила поддержки и метаданные основной конфигурации хранятся во внутренних системных таблицах базы данных. При выполнении обновления через поддержку измененные метаданные и новая конфигурация поставщика сначала помещаются во временную область — таблицу ConfigSave. Перенос данных в рабочую таблицу Config происходит только при успешном завершении реструктуризации и обновлении конфигурации базы данных (по нажатию F7). Если во время объединения или сохранения происходит непредвиденный сбой, аварийное завершение процесса или нехватка памяти, платформа сбрасывает незафиксированные изменения и откатывает состояние конфигурации поставщика к исходному из таблицы Config.
2. Откат служебных транзакций при запуске «1С:Предприятия». Если обновление метаданных прошло успешно, но при старте пользовательского сеанса обработчик обновления данных (механизмы БСП или типовой конфигурации) завершается с критической ошибкой, транзакция записи актуальных номеров версий в регистры сведений (например, ВерсииПодсистем) отменяется. При повторном открытии Конфигуратора база данных воспринимается как недообновленная.
3. Утечка памяти и залипание внутреннего кэша 1cv8.exe. В процессе установки нескольких обновлений подряд без перезапуска Конфигуратора процесс накапливает в оперативной памяти сотни мегабайт кэшированных структур метаданных. В линейках платформы 8.3 при работе со старыми конфигурациями в режиме совместимости с версией 8.2 такое переполнение памяти часто приводит к тому, что ссылки на дескрипторы конфигурации поставщика не сбрасываются вовремя на диск.
4. Локальный кэш пользователя. Поврежденный кэш конфигурации на клиентском компьютере может приводить к тому, что Конфигуратор и режим Предприятия считывают устаревшие описания структур данных из локальных временных файлов.

Способ 1. Разделение шагов сохранения и отказ от немедленного обновления базы данных

Главная ошибка при накатывании длинной цепочки релизов — спешка и автоматическое согласие на все всплывающие диалоговые окна платформы. Применим метод раздельного сохранения метаданных, который исключает сбои в таблицах ConfigSave.

Разберем последовательность действий по шагам:

1. Откроем Конфигуратор и запустим процесс обновления штатным образом: меню Конфигурация → Поддержка → Обновить конфигурацию.
2. Укажем путь к файлу обновления (.cfu или .cf) следующего по порядку релиза.
3. В окне сравнения и объединения проверим сопоставление объектов и нажмем кнопку Выполнить.
4. После завершения объединения система выдаст диалоговое окно с вопросом: «Обновить конфигурацию базы данных?». Нажмем «Нет»! Ни в коем случае не обновляем конфигурацию базы данных мгновенно.
5. Перейдем в меню Конфигурация → Поддержка → Настройка поддержки. Проверим, что в графе «Конфигурация поставщика» зафиксирован правильный, только что примененный номер версии. Закроем окно настройки поддержки.
6. Явно сохраним основную конфигурацию, нажав сочетание клавиш Ctrl + S, либо выбрав пункт меню Конфигурация → Сохранить конфигурацию. Дождемся завершения сохранения в строке состояния.
7. Только после этого инициируем обновление конфигурации базы данных, нажав клавишу F7 (или пункт меню Конфигурация → Обновить конфигурацию базы данных).
8. Применим изменения в окне реструктуризации таблиц.
9. Запустим сеанс «1С:Предприятие» в режиме отладки (F5), дождемся отработки всех регламентных процедур и служебных обработчиков обновления данных, убедимся в успешном открытии рабочего стола и только затем закроем программу.

Способ 2. Очистка кэша и перезапуск процесса Конфигуратора

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

Разберем процедуру:

1. Полностью закроем все запущенные сеансы «1С:Предприятия» и Конфигуратора. Проверим через диспетчер задач операционной системы, что процессы 1cv8.exe и 1cv8c.exe полностью завершены.
2. Очистим папки локального кэша платформы. Для этого перейдем в директории:
   %LocalAppData%\1C\1cv8\
%AppData%\1C\1cv8\
   и удалим все каталоги с уникальными буквенно-цифровыми идентификаторами (вида d41d8cd9-8f00-b204-e980...).
3. В качестве альтернативного и более надежного метода удалим базу из списка запуска 1С и добавим ее заново под тем же путем. При этом платформа сформирует для базы совершенно новый чистый каталог кэша.
4. Важное правило: при установке более 2–3 релизов подряд обязательно полностью закрываем Конфигуратор после каждого успешного релиза и открываем его заново. Это освобождает дескрипторы оперативной памяти и гарантирует корректную запись метаданных в базу.

Способ 3. Ручная синхронизация конфигурации поставщика (если она отстала)

Рассмотрим частую критическую ситуацию: основная конфигурация уже обновлена (например, до версии 2.0.16.1), а конфигурация поставщика осталась на версии 2.0.15.5. При попытке применить следующий релиз Конфигуратор выдает ошибку совместимости.

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

1. Откроем меню Конфигурация → Поддержка → Обновить конфигурацию.
2. Выберем файл обновления того релиза, на котором должна находиться конфигурация поставщика (в нашем примере — 2.0.16.1), или полный файл .cf этого релиза.
3. Дойдем до окна сравнения и объединения конфигураций.
4. Главное действие: снимем корневой флажок в дереве объектов метаданных. Убедимся, что абсолютно со всех объектов сняты флажки объединения (ни один объект основной конфигурации не должен быть затронут или перезаписан).
5. Нажмем кнопку Выполнить.

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

Способ 4. Проверка целостности таблиц информационной базы

Если конфигурация поставщика регулярно откатывается назад даже при соблюдении регламента, причиной может быть повреждение внутренней структуры файла 1Cv8.1CD (для файловых баз). Проверим базу на ошибки:

1. Создадим резервную копию базы данных (выгрузка в файл .dt или прямое копирование файла 1Cv8.1CD).
2. Запустим утилиту проверки целостности файловой базы chdbfl.exe (располагается в папке bin установленной версии платформы). Установим флаг «Исправлять обнаруженные ошибки» и выполним проверку.
3. Запустим Конфигуратор и откроем меню Администрирование → Тестирование и исправление...
4. Отметим флажками следующие пункты:
   • Проверка логической целостности конфигурации;
   • Проверка ссылочной целостности информационной базы;
   • Реиндексация таблиц информационных баз;
   • Пересчет итогов.
5. Нажмем Выполнить и дождемся завершения протокола тестирования.

Способ 5. Обновление через промежуточные узловые релизы (файлы .cf)

Последовательное обновление через 15–20 файлов .cfu — долгий процесс, многократно увеличивающий вероятность ошибок. Фирма «1С» регулярно выпускает полные файлы поставки (.cf) для так называемых ключевых или узловых релизов.

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

Резюме

Чтобы избежать отката и рассинхронизации конфигурации поставщика при масштабных обновлениях, придерживаемся следующих правил:

1. Не нажимаем немедленное согласие на обновление конфигурации базы данных в окне объединения. Сначала применяем метаданные, проверяем статус в окне поддержки, явно сохраняем конфигурацию (Ctrl + S) и лишь затем нажимаем F7.
2. Обязательно запускаем «1С:Предприятие» после каждого релиза и даем отработать процедурам обновления данных.
3. Перезапускаем процесс Конфигуратора после каждых 1–2 установленных релизов для сброса оперативной памяти.
4. Регулярно очищаем временный кэш платформы при малейших признаках некорректного отображения номеров версий.