Основная конфигурация отличается от конфигурации базы данных 1С: причины и решение

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

Ситуация штатная: так задуман механизм разработки в 1С. Расхождение возникает после доработки типовой конфигурации, загрузки обновления из файла, объединения конфигураций или прерванного обновления. Проблема лишь в том, что до завершения обновления база может находиться в несогласованном состоянии, а часть пользователей — получать ошибки.

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

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

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

Типичные причины расхождения:

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

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

Что проверить перед обновлением

Обновление конфигурации базы данных требует монопольного доступа: ни один пользователь и ни один сеанс (включая фоновые задания и соединения веб-сервисов) не должны быть подключены к базе. В клиент-серверном варианте проверьте список сеансов в консоли кластера, в файловом — убедитесь, что все коллеги вышли, и нет зависших процессов 1cv8.exe.

Обязательно сделайте резервную копию. Для файловой базы достаточно выгрузки через «Администрирование → Выгрузить информационную базу» в файл .dt — такой файл содержит и данные, и конфигурацию. Для клиент-серверной базы правильнее сделать средствами СУБД (например, backup в MS SQL или PostgreSQL), потому что выгрузка .dt большой базы занимает много времени и места.

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

Как выполнить обновление конфигурации базы данных

Стандартная процедура одинакова для типовых и доработанных конфигураций:

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

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

На больших базах реструктуризация может идти долго — от нескольких минут до часов. Не прерывайте процесс кнопкой «Отмена» или закрытием конфигуратора: прерванная реструктуризация — один из главных источников повреждённых баз. Если кажется, что процесс завис, проверьте активность на стороне СУБД или диска, прежде чем принимать решение.

Что делать, если обновление не выполняется

Наиболее частая ошибка — «Невозможно установить монопольный режим». Она означает, что к базе остаются подключения. В файловом варианте проверьте зависшие процессы 1cv8.exe на компьютерах пользователей и на сервере, где лежит база. В клиент-серверном — откройте консоль кластера и завершите лишние сеансы; также проверьте, не блокирует ли базу запущенный агент фоновых заданий.

Ошибка «Конфигурация базы данных не требует обновления» при явных расхождениях

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

Ошибки прав доступа и динамическое обновление

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

Как проверить результат после обновления

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

Запустите базу в режиме «Предприятие» и проверьте объекты, которые менялись: откройте изменённые документы, сформируйте отчёты по новым реквизитам, выполните типовые операции. Если обновление затрагивало движения документов или регистры, имеет смысл запустить обработчики обновления данных — в типовых конфигурациях на БСП они выполняются автоматически при первом запуске и отображаются в окне «Обновление версии программы».

Контрольные точки

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

Сообщение о расхождении конфигураций

Норма

При входе в конфигуратор предупреждения нет, пункт обновления неактивен

Тревожный признак

Предупреждение появляется снова — обновление не завершилось

Работа изменённых объектов

Норма

Документы, отчёты и справочники открываются и работают без ошибок

Тревожный признак

Ошибки «Поле не обнаружено» или падение при открытии объектов

Работа пользователей после запуска

Норма

Все сеансы подключаются штатно, ошибок кэша метаданных нет

Тревожный признак

«Ошибка формата потока» — нужно очистить кэш пользователей

Профилактика: как не допускать расхождений

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

Полезные практики:

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

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

Частые вопросы

Можно ли работать в базе, пока конфигурации различаются?

Технически пользователи продолжают работать со старой структурой, и данные не портятся. Но новые объекты и реквизиты им недоступны, а откладывание обновления повышает риск забыть о нём и столкнуться с конфликтом при следующем обновлении. Лучше применять изменения сразу.

Что такое динамическое обновление и когда им можно пользоваться?

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

Обновление прервалось на середине — база испорчена?

Не обязательно, но риск высок. Не запускайте повторное обновление сразу. Сделайте выгрузку .dt (если база открывается), затем выполните тестирование и исправление с проверкой физической и логической целостности. Если база не открывается — восстанавливайтесь из резервной копии.

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

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

Как узнать, чем именно отличаются конфигурации?

Используйте «Конфигурация → Сравнить, объединить с конфигурацией из файла» или сравнение с конфигурацией базы данных через соответствующие пункты меню. Платформа покажет список различающихся объектов. Это помогает понять масштаб изменений до запуска обновления.

Нужно ли обновление, если менялись только модули?

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