← На главную

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

Причины сбоя штатного механизма обновления

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

1. Повреждение внутренних потоков метаданных: в служебных таблицах Config, ConfigSave или Params накапливаются некорректные бинарные данные, которые не затрагивают физическую целостность таблиц базы, но вызывают сбой парсера конфигуратора при попытке автоматического слияния версий.
2. Коллизии предопределенных элементов: расхождение внутренних идентификаторов (GUID) или системных имен предопределенных объектов между текущей базой и файлом обновления блокирует процедуру реорганизации данных.
3. Исчерпание адресного пространства 32-разрядного конфигуратора: при объемном сравнении метаданных процесс может аварийно завершаться из-за нехватки оперативной памяти.
4. Ошибки кэширования: некорректно сформированный локальный кэш пользователя или серверный кэш сеансов в каталоге кластера серверов srvinfo провоцирует ложные сбои при применении структуры метаданных.

Способ 1. Обновление через подготовку полного CF-файла в пустой базе

Рассмотрим основной проверенный способ обхода ошибки, когда штатное инкрементное обновление не срабатывает:

1. Создаем новую пустую информационную базу без конфигурации.
2. Разворачиваем в чистой базе исходный релиз (в рассматриваемом случае — 2.0.66.3) с помощью полного файла поставщика (.cf) или обновляем ее до целевого релиза последовательной установкой пакетов .cfu.
3. Доводим пустую базу до нужного финального релиза (например, 2.0.66.10).
4. Сохраняем полную конфигурацию в файл: открываем меню Конфигурация — Сохранить конфигурацию в файл... и получаем готовый файл 1Cv8.cf целевой версии.
5. Создаем резервную копию рабочей базы: обязательно выполняем выгрузку рабочей базы в файл .dt или делаем резервную копию средствами СУБД (PostgreSQL, MS SQL).
6. Загружаем конфигурацию в рабочую базу: в конфигураторе рабочей информационной базы открываем меню Конфигурация — Загрузить конфигурацию из файла... и выбираем сохраненный на предыдущем шаге файл 1Cv8.cf. Соглашаемся на полную замену конфигурации.
7. Применяем изменения: нажимаем клавишу F7 или кнопку «Обновить конфигурацию базы данных» и подтверждаем реорганизацию структуры.

Важный шаг: правильное восстановление типовой поддержки

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

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

Способ 2. Пересборка конфигурации через выгрузку в файлы

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

1. В конфигураторе проблемной базы выбираем меню Конфигурация — Выгрузить конфигурацию в файлы... и указываем пустой каталог на диске. В процессе выгрузки платформа заново сериализует все метаданные в XML-файлы, отсекая битые внутренние потоки.
2. Создаем пустую информационную базу.
3. В меню конфигуратора пустой базы выбираем Конфигурация — Загрузить конфигурацию из файлов... и указываем каталог с выгруженными файлами.
4. После успешной загрузки сохраняем конфигурацию в файл .cf и используем его для обновления рабочей базы.

Способ 3. Очистка серверного и локального кэша

Выясним, как исключить влияние временных файлов на процесс обновления в клиент-серверном варианте (PostgreSQL):

1. Очистка локального кэша: удаляем содержимое каталогов %LocalAppData%\1C\1cv8 и %AppData%\1C\1cv8 на рабочем месте, где запускается конфигуратор.
2. Очистка серверного кэша: останавливаем службу сервера «1С:Предприятия» (ragent), переходим в каталог кластера (по умолчанию srvinfo) и удаляем вложенные папки сеансовых данных snccntx*, после чего перезапускаем службу.
3. Использование 64-разрядного клиента: запускаем процедуру обновления с использованием 64-битной версии конфигуратора, чтобы исключить падения по причине нехватки оперативной памяти при сопоставлении больших объемов метаданных.