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

Программист 1С v8.3 (Управляемые формы) 1С:Розница Торговля и дистрибуция
← На главную

При обновлении конфигураций 1С (в частности, при переходе со старых редакций на новые, например, с «Розницы» редакции 1.0 на 2.2) разработчики иногда сталкиваются с неожиданным предупреждением диалогового окна: «Обновление конфигурации базы данных будет выполнено на сервере. Отказ от принятия изменений будет невозможен. Продолжить?». При этом информационная база является строго файловой, сервер 1С:Предприятия не задействован, а распределенная информационная база (РИБ) отключена через ПланыОбмена.УстановитьГлавныйУзел(Неопределено).

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

Причины появления сообщения о серверном обновлении в файловой базе

Выясним, откуда в локальной файловой базе может появиться упоминание сервера и почему платформа блокирует интерактивный отказ от изменений структуры данных:

  1. Служебный вызов команды фонового обновления: В платформе 1С:Предприятие 8.3 механизм обновления базы данных разделен на интерактивный и безусловный («на сервере»). В конфигураторе присутствует отдельный пункт меню: «Конфигурация» → «Конфигурация базы данных» → «Обновить конфигурацию базы данных на сервере» (аналогичный запуск выполняется из командной строки с параметром -Server). Даже в файловом варианте платформа эмулирует серверные вызовы в рамках локального процесса. Если случайно нажать эту команду или вызвать ее комбинацией горячих клавиш вместо стандартного обновления (клавиша F7), платформа запустит реструктуризацию без возможности отката.
  2. Включение оптимизированной реструктуризации v2: Если в конфигурационном файле conf.cfg включен параметр UpdateDBCfg=v2, платформа применяет альтернативный механизм реструктуризации таблиц. В этом режиме данные переносятся в параллельные временные таблицы с последующей быстрой подменой, поэтому интерактивный диалог со списком изменений и кнопкой отмены технически отключается.
  3. Зависшие флаги незавершенного обновления или РИБ: При аварийном завершении предыдущего сеанса обновления, сбое синхронизации или некорректном отключении узла распределенной базы во внутренних системных таблицах (CONFIG, CONFIGSAVE, PARAMS) остаются служебные маркеры незавершенной реструктуризации. Платформа считает, что база находится в переходном состоянии, и пытается завершить процедуру в принудительном режиме.

Шаг 1. Внутреннее и внешнее тестирование и исправление базы данных

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

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

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

Шаг 2. Устранение сопутствующих ошибок совместимости (ошибка СтрШаблон)

Нередко при переходе между поколениями конфигураций сохранение изменений прерывается синтаксическими ошибками, например, реакцией встроенного контроля на метод СтрШаблон. Разберем причину этого явления:

Функция СтрШаблон появилась в платформе версии 8.3.6. Конфигурации старых редакций (такие как «Розница 1.0») разрабатывались для платформ 8.1 или 8.2, и в свойствах корневого узла конфигурации задан соответствующий режим совместимости (например, «Версия 8.2.13» или «Версия 8.3.5»).

Если в обновляемом коде новой редакции уже используются современные конструкции языка, а режим совместимости еще не переключен, синтаксический контроль платформы выдает ошибку. Чтобы исправить эту ситуацию, откроем свойства корневого узла дерева метаданных и в свойстве «Режим совместимости» установим значение, требуемое для обновленного релиза конфигурации (для современных редакций — версия платформы 8.3.8, 8.3.10 или «Не использовать»).

Шаг 3. Решение проблем с блокировкой документов и пользователями ИБ

При переходе на конфигурации, использующие Библиотеку стандартных подсистем (БСП), часто возникают вторичные ошибки:

  1. Недоступность кнопок проведения и записи в документах (например, «Установка цен номенклатуры»): Отключения главного узла через метод ПланыОбмена.УстановитьГлавныйУзел(Неопределено) может быть недостаточно. В прикладных механизмах «Розницы» действуют внутренние проверки узла распределения цен в справочнике магазинов. Если магазин не отмечен как центральный или управляющий, редактирование цен блокируется на уровне модулей объектов и форм. Необходимо проверить настройки структуры сети и распределения торговых точек.
  2. Ошибка «ПользовательИБ не найдено»: В современных конфигурациях список пользователей жестко синхронизируется с системной таблицей ПользователиИнформационнойБазы через служебные реквизиты и уникальные идентификаторы (UUID). Не запускайте внешние обработки до тех пор, пока база не будет запущена в режиме «1С:Предприятие» под учетной записью с полными правами и пока не завершатся все фоновые процедуры первоначального заполнения и обновления данных новой редакции.

Шаг 4. Пересоздание базы через выгрузку и загрузку файла выгрузки (.dt)

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

  1. В конфигураторе перейдем в меню «Администрирование» → «Выгрузить информационную базу...» и сформируем архивный файл .dt.
  2. Создадим в каталоге новую пустую информационную базу.
  3. Запустим конфигуратор новой базы и выполним команду «Администрирование» → «Загрузить информационную базу...».
  4. Очистим кэш конфигуратора и сеансов пользователя, удалив папки по путям %LOCALAPPDATA%\1C\1Cv8 и %APPDATA%\1C\1Cv8.

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

← На главную