← На главную

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

Понимание структуры конфигураций в 1С

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

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

Разберем ситуацию автора: конфигурация поставщика была обновлена до релиза 110, но конфигурация базы данных осталась на 109-м. Это означает, что структура таблиц в SQL еще соответствует старому релизу, что дает нам пространство для маневра.

Диагностика текущего состояния системы

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

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

Рассмотрим подробнее способ точной проверки версий. Для этого выполним следующие шаги:

1. Перейдем в меню Конфигурация — Поддержка — Настройка поддержки. Здесь мы увидим версию конфигурации поставщика (в примере автора это был бы 110 релиз).
2. Кликнем правой кнопкой мыши на корень конфигурации и выберем Свойства. В поле «Версия» указана версия основной конфигурации.
3. Зайдем в режим «Предприятие» и в меню «О программе» проверим версию конфигурации. Это и есть версия конфигурации БД.

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

Вариант 1: Возврат к конфигурации базы данных

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

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

Вариант 2: Использование CF-файла для отката

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

1. Выгрузим «рабочую» конфигурацию базы данных (если мы уверены, что она стабильна) в файл: Конфигурация — Конфигурация БД — Сохранить конфигурацию БД в файл....
2. Загрузим этот файл в основную конфигурацию через Конфигурация — Загрузить конфигурацию из файла.... Внимание! Этот метод полностью заменяет дерево объектов и настройки поддержки.
3. После загрузки мы можем внести необходимые исправления (hotfix) непосредственно в 109-й релиз.

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

Вариант 3: Исправление ошибки через расширение (Hotfix)

Если конфигурация поставщика уже обновлена до 110, а конфигурация БД все еще 109, и при этом нужно срочно исправить ошибку, не завершая общее обновление, — лучшим инструментом будет расширение конфигурации.

Вместо того чтобы мучительно откатывать основную конфигурацию, мы создаем новое расширение и переносим туда ошибочный метод или объект. Исправляем код в расширении и подключаем его. Пользователи продолжат работать на 109-м релизе с исправленной ошибкой, а вы сможете спокойно дотестировать 110-й релиз на копии базы.

Организация процесса разработки и обновлений

Чтобы не попадать в ситуацию «кривого» обновления на живой базе, разберем правильный цикл разработки, который упоминали участники обсуждения:

1. Тестовая база: Все обновления сначала проводятся на полной копии рабочей базы (для экономии времени администратора возможна установка нескольких обновлений типовых конфигураций одним кликом). Здесь выполняются все процедуры ОбновлениеИнформационнойБазыБП.
2. Хранилище конфигурации: Использование хранилища позволяет фиксировать стабильные версии и откатываться к ним в случае неудачи.
3. Снятие с поддержки или расширения: В КОРП-версиях крайне не рекомендуется полностью снимать базу с поддержки. Лучше использовать режим «Объект поставщика редактируется с сохранением поддержки» или выносить все доработки в расширения. Это значительно упрощает последующие обновления через сравнение и объединение.

Важные замечания по динамическому обновлению

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

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