← На главную

Рассмотрим достаточно распространенную и неприятную ситуацию, возникающую при обновлении типовых конфигураций (например, «Бухгалтерия предприятия» редакции 2.0). При попытке накатить обновление (файл .cfu) через конфигуратор платформа выдает сообщение: «Файл не содержит доступных обновлений». При этом в окне выбора конфигураций нужный релиз присутствует. Дополнительно в журнале регистрации может появляться запись: «Для выполнения команды требуется разблокировать все объекты», а на некоторых версиях платформы случается аварийное завершение работы (Runtime error).

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

Основные причины возникновения ошибки

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

1. Несовпадение ветки поставки (ПРОФ, КОРП, Базовая). Дистрибутив обновления скачан для другой версии продукта. Например, вы пытаетесь обновить базовую версию файлом для версии ПРОФ. У них разные внутренние идентификаторы, поэтому платформа бракует файл .cfu.
2. Рассинхронизация конфигурации поставщика. Файл .cfu содержит разницу (дифф) не с текущей конфигурацией базы данных, а со строго определенным эталонным снимком метаданных конфигурации поставщика. Если ранее базу обновляли некорректно (через команду «Сравнить, объединить...» без настройки правил поддержки), внутренняя таблица конфигурации поставщика остается старой. Платформа «видит» этот старый релиз под капотом и сообщает об отсутствии обновлений.
3. Проблемы с блокировками объектов. Ошибка с требованием разблокировать объекты возникает, если база ранее была подключена к Хранилищу конфигурации 1С и остались зависшие захваченные объекты. Также это происходит, если поврежден кэш прав поддержки и платформа пытается изменить объект, для которого жестко установлено правило «Объект поставщика не редактируется».

Анализ ситуации: скрытые нетиповые изменения

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

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

Безопасное восстановление конфигурации поставщика

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

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

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

Особенности работы с платформой и проверка целостности

Рассмотрим дополнительные технические нюансы, которые необходимо учитывать при обновлении старых конфигураций на обычных формах.

Аварийное завершение на платформе 8.3: Конфигурации линейки 2.0 разрабатывались под платформу 8.2 (режимы совместимости 8.2.13 или 8.2.16). При выполнении тяжелых операций реструктуризации или сравнения/объединения на ранних и промежуточных релизах 8.3 (например, 8.3.8) Конфигуратор может падать с ошибкой Runtime error из-за несовместимости графической подсистемы обычных форм. Промежуточные обновления внутри ветки 2.0 рекомендуется выполнять на стабильных релизах платформы 8.2 (например, 8.2.19.130). Переходить на 8.3 следует только непосредственно перед финальным обновлением на редакцию 3.0.

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

1. Проверьте файл базы данных (1Cv8.1CD) утилитой chdbfl.exe (находится в папке bin установленной платформы).
2. В Конфигураторе запустите Тестирование и исправление с отмеченными пунктами «Проверка логической целостности» и «Реструктуризация таблиц информационной базы».
3. Обязательно очистите кэш сеансовых данных 1С, так как поврежденный кэш часто блокирует процесс обновления конфигурации.