Что делать, если при обновлении 1С:УПП версия конфигурации не меняется, а релиз поддержки растет?

Программист 1С v8.3 (Обычные формы)
← На главную

При обновлении сложных и кастомизированных систем, таких как 1С:Управление производственным предприятием 1.3 (УПП), специалисты часто сталкиваются с парадоксальной ситуацией. После выполнения всех процедур обновления в Конфигураторе через файл .cfu или .cf, система сообщает об успешном завершении, однако в окне «О программе» номер релиза остается прежним (например, 1.3.121.1), хотя «Настройка поддержки» показывает, что конфигурация поставщика уже обновлена до следующего актуального релиза (например, 1.3.122.3).

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

Выясним причину: почему релиз «застревает»?

Для начала проанализируем механизм того, как платформа 1С понимает, какой номер версии присвоить конфигурации. Номер версии — это не просто текст, это свойство корневого объекта метаданных. Когда мы запускаем процедуру сравнения и объединения, платформа сопоставляет текущую версию основной конфигурации с версией поставщика.

Рассмотрим основные причины сбоя:

  1. Снятая галочка на «корне» конфигурации: Это самая частая причина. В окне «Сравнение и объединение» в самом верху дерева находится объект «Конфигурация». Если в вашей базе были внесены изменения в свойства конфигурации (например, изменен комментарий, автор или режим совместимости), платформа может автоматически не отметить этот узел для обновления. В итоге: все справочники и документы обновляются, а свойство Версия остается старым.
  2. Кэш конфигуратора и сервера: Платформа 1С активно использует кэширование метаданных. Иногда после обновления базы данных физические таблицы Config и ConfigSave в SQL-базе обновляются, но клиентское приложение продолжает «видеть» старые значения из локального кэша.
  3. Использование только файлов обновления (.cfu): При перескакивании через несколько релизов или при наличии специфических доработок, цепочка файлов обновления может отработать некорректно в части обновления идентификаторов версий.
  4. Блокировки в таблицах базы данных: В редких случаях при записи изменений в системные таблицы СУБД происходит сбой, который не приводит к критической ошибке, но блокирует обновление записи о текущей версии.

Решение 1: Проверка настроек сравнения и объединения

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

  1. Зайдите в меню «Конфигурация» — «Поддержка» — «Настройка поддержки».
  2. В открывшемся окне нажмите кнопку «Сравнить и объединить».
  3. Дождитесь завершения анализа (это может занять значительное время для УПП).
  4. В появившемся окне «Сравнение и объединение» найдите самую верхнюю строку (имя вашей конфигурации).
  5. Внимание: Убедитесь, что галочка на этом объекте стоит. Если она не стоит, установите ее.
  6. В колонке «Режим объединения» для корня конфигурации должно быть выбрано «Взять из конфигурации поставщика».
  7. Нажмите кнопку «Выполнить» и подтвердите обновление.

После этого обязательно нажмите F7 (Обновить конфигурацию базы данных) и запустите программу в режиме «Предприятие» для выполнения обработок обновления данных.

Решение 2: Полная чистка кэша и «перерегистрация» базы

Если манипуляции в Конфигураторе не помогают, проанализируем ситуацию с точки зрения платформенных механизмов. Часто проблема решается простым удалением базы из списка и повторным добавлением. Разберем этот процесс подробнее:

  1. Закройте все сеансы работы с базой.
  2. Удалите базу из списка в окне запуска 1С.
  3. Очистите содержимое папок кэша (обычно находятся в %AppData%\1C\1Cv8\ и %LocalAppData%\1C\1Cv8\).
  4. Добавьте базу в список заново под тем же именем.
  5. Если база серверная, может потребоваться перезагрузка службы 1C:Enterprise 8.3 Server Agent, так как сервер тоже хранит кэш метаданных.

Решение 3: Метод «Транзитной базы» (выгрузка/загрузка .dt)

Как отметил автор вопроса в одном из сообщений, создание новой базы через файл выгрузки помогает решить проблему. Проанализируем, почему это работает. При загрузке файла .dt платформа фактически пересоздает структуру таблиц в СУБД с нуля. Это устраняет любые логические несоответствия в системных таблицах Config.

Порядок действий:

  1. Сделайте выгрузку информационной базы (Администрирование — Выгрузить информационную базу...).
  2. Создайте пустую базу на том же сервере СУБД.
  3. Загрузите в нее полученный .dt.
  4. Попробуйте выполнить обновление в новой базе.

Решение 4: Обновление через полный файл конфигурации (.cf)

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

Выясним, какой релиз сейчас реально установлен в конфигурации поставщика. Допустим, это 1.3.122.3. Возьмите чистый файл 1cv8.cf этого же релиза и выполните сравнение:

  1. Меню «Конфигурация» — «Сравнить, объединить с конфигурацией из файла...».
  2. Выберите файл .cf нужного релиза.
  3. В окне сравнения снимите галочки со всех объектов, кроме самого верхнего (корня).
  4. Выполните объединение. Это принудительно обновит номер версии в свойствах, не затрагивая ваши программные доработки.

Важное замечание про режим совместимости

Проанализируем еще один тонкий момент. В конфигурации УПП 1.3 версии 1.3.121 и выше часто менялись требования к режиму совместимости платформы. Если в вашей основной конфигурации режим совместимости зафиксирован вручную (например, «Версия 8.2.13»), а обновление требует «Версия 8.3.14», платформа может блокировать запись обновленных свойств конфигурации.

Проверьте свойство: Конфигурация (корень) -> Свойства -> Совместимость -> Режим совместимости. Оно должно соответствовать тому, которое установлено в конфигурации поставщика для данного релиза.

Как проверить результат?

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


// Пример проверки версии через встроенный язык
Сообщить(Метаданные.Версия);

Если номер версии теперь совпадает с версией поставщика, значит, проблема решена, и при следующем обновлении система корректно предложит вам список доступных обновлений .cfu.

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

← На главную