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

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

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

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

Что физически означает это сообщение

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

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

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

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

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

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

Подготовка перед исправлением

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

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

Пошаговое исправление через конфигуратор

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

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

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

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

Если стандартный способ не помог

Иногда обновление конфигурации базы данных завершается с ошибкой или сообщение о несоответствии появляется снова. Первым делом в такой ситуации очистите кэш метаданных: для файловой базы удалите папку с кэшем в каталоге пользователя (путь вида %APPDATA%\1C\1cv8\<идентификатор базы>) или удалите базу из списка и добавьте заново. Устаревший кэш — частая причина «фантомного» рассинхронизирования.

Следующий шаг — тестирование и исправление информационной базы («Администрирование → Тестирование и исправление» в конфигураторе). Запускайте его только на копии или при наличии свежего бэкапа: режимы исправления могут удалять повреждённые записи. Для файловых баз также полезна проверка физической целостности утилитой chdbfl.exe из каталога установки платформы.

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

Профилактика и особенности клиент-серверного режима

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

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

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

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

Запуск режима «Предприятие»

Норма

База открывается без сообщения о несоответствии

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

Сообщение появляется снова — очистите кэш и повторите обновление

Окно реструктуризации

Норма

Список содержит только ожидаемые изменения

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

Есть удаление нужных таблиц или полей — остановитесь и разберитесь

Обработчики обновления

Норма

Все обработчики выполнены, версия в «О программе» новая

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

Обработчики зависли или с ошибками — смотрите журнал регистрации

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

Норма

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

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

Ошибки обращения к объектам — обновление не применено полностью

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

Можно ли работать в базе, если игнорировать это сообщение?

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

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

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

Ошибка появилась, хотя никто ничего не обновлял. Что делать?

Чаще всего виноват кэш метаданных на клиенте. Удалите базу из списка информационных баз и добавьте заново, либо очистите папку кэша в профиле пользователя. Если не помогло — проверьте базу утилитой chdbfl (файловый вариант) и выполните тестирование и исправление на копии.

Чем отличается «Сохранить конфигурацию» от «Обновить конфигурацию базы данных»?

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

Нужен ли монопольный доступ для исправления?

Да. Обновление конфигурации базы данных выполняется только при монопольном доступе: все сеансы пользователей и фоновые задания должны быть завершены. В клиент-серверном режиме сеансы удобно завершать через консоль кластера серверов 1С.

Обновление зависло на реструктуризации большой таблицы. Прерывать?

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