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

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

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

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

Что такое основная конфигурация и где она хранится

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

Физически основная конфигурация хранится внутри файла базы данных (в файловом варианте — в файле 1Cv8.1CD, в клиент-серверном — в служебных таблицах СУБД), но в отдельной области, отличной от той, по которой построены рабочие таблицы. При сохранении конфигурации (команда «Сохранить конфигурацию» или Ctrl+S) изменения фиксируются именно в этой области.

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

Что такое конфигурация базы данных

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

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

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

Ключевые отличия: таблица сравнения

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

Из таблицы следует главный практический вывод: конфигурация базы данных никогда не меняется «сама» и не правится вручную. Любая попытка привести её в нужное состояние возможна только через обновление из основной конфигурации либо через загрузку файла конфигурации с последующим обновлением.

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

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

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

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

Если в базе работают пользователи, обновление в монопольном режиме может быть невозможно. Для клиент-серверных баз существует динамическое обновление, но оно имеет серьёзные ограничения и подходит не для всех изменений — об этом ниже.

Динамическое обновление: когда можно и когда нельзя

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

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

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

Типичные ошибки и расхождения конфигураций

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

Более неприятный сценарий — когда основная конфигурация оказалась «старше» или «младше» конфигурации базы данных из-за некорректной загрузки файлов .cf или восстановления из копии. Определить, какая из конфигураций актуальна, помогает сравнение: откройте конфигурацию базы данных на просмотр и сопоставьте версию и состав объектов с основной.

Как проверить, что конфигурации синхронизированы

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

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

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

Запуск отладки из конфигуратора

Норма

База запускается без предупреждений о несоответствии конфигураций

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

Появляется сообщение «Конфигурация базы данных не соответствует сохранённой конфигурации»

Новые объекты в конфигурации базы данных

Норма

Добавленные справочники, реквизиты и отчёты видны в режиме просмотра

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

Объектов нет — обновление не выполнялось или завершилось с ошибкой

Работа пользователей в режиме предприятия

Норма

Документы проводятся, отчёты формируются, новые поля доступны

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

Ошибки «Поле не найдено» или падение запросов с новыми реквизитами

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

Практические рекомендации по работе с двумя конфигурациями

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

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

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

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

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

Почему я сохранил конфигурацию, а пользователи не видят изменений?

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

Можно ли редактировать конфигурацию базы данных напрямую?

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

Что делать, если обновление требует монопольного режима, а пользователи работают?

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

Откуда берётся сообщение «Конфигурация базы данных не соответствует сохранённой конфигурации»?

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

Опасно ли прервать реструктуризацию в процессе обновления?

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

Чем отличается конфигурация поставщика от двух описанных?

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