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

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

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

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

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

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

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

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

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

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

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

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

Зачем нужны две конфигурации одновременно

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

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

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

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

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

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

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

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

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

Динамическое обновление

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

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

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

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

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

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

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

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

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

Команда обновления базы данных

Норма

Неактивна — конфигурации совпадают

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

Активна — изменения не применены до конца

Сравнение конфигураций

Норма

Список отличий пуст

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

Есть различающиеся объекты

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

Норма

База открывается, формы работают

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

Ошибки модулей или сообщения о реструктуризации

Часто задаваемые вопросы

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

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

Почему пользователи не видят мои изменения после сохранения?

Сохранение (Ctrl+S) записывает только основную конфигурацию. Чтобы изменения заработали, нужно выполнить «Обновить конфигурацию базы данных» (F7), а пользователям — перезапустить сеанс.

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

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

Что будет, если прервать реструктуризацию?

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

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

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

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

Если используется хранилище конфигурации, история изменений доступна по каждому объекту с указанием автора и версии. Без хранилища остаётся только сравнение с конфигурацией базы данных или с сохранённым файлом .cf — оно покажет список изменённых объектов, но не автора правок.