Почему изменения конфигурации не переносятся в периферийную базу РИБ?

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

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

Основная причина заключается в рассинхронизации конфигурации базы данных (БД) и метаданных. Платформа 1С хранит конфигурацию в нескольких системных таблицах (в SQL это Config и ConfigSave). При выполнении обновлений, особенно если ранее использовалось «демоническое обновление» или если процесс обмена прерывался, во внутренних таблицах могут остаться «битые» данные или устаревшие хэши объектов.

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

Метод 1: Принудительное изменение метаданных объекта

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

1. Откройте конфигуратор в центральной базе.
2. Найдите проблемный модуль или документ, в котором вы видите различие.
3. Внесите любое незначительное изменение в структуру этого объекта. Например, добавьте временный реквизит или измените длину существующей строки.
4. Сохраните изменения в конфигурации. Это заставит платформу пересчитать хэш объекта и принудительно обновить его структуру в базе данных.
5. После выполнения обмена убедитесь, что изменения дошли до периферийной базы.
6. Теперь можно вернуть объект в исходное состояние — система должна корректно зафиксировать и передать «исправление».

Метод 2: Очистка кэша и принудительная загрузка конфигурации

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

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

Шаг 2: Отвязка от главного узла. Чтобы конфигурация не «сопротивлялась» изменениям со стороны центра, можно временно снять признак РИБ:

// В конфигураторе периферийной базы:
// 1. ПланОбмена.УдалитьГлавныйУзел();
// 2. После этого база становится «автономной».

Шаг 3: Полная загрузка конфигурации. Выгрузите конфигурацию из центральной базы в файл *.cf. Затем в периферийной базе выполните команду Загрузить конфигурацию из файла. В отличие от объединения, полная загрузка конфигурации замещает все модули системы.

Метод 3: Очистка системных таблиц SQL

Если вы работаете с MS SQL Server и предыдущие методы не принесли результата, можно попробовать очистить таблицы хранения конфигурации. Внимание: делайте это только на копии базы!

Выполните truncate для системных таблиц, отвечающих за хранение конфигурации. Рассмотрим пример запроса:

TRUNCATE TABLE dbo.ConfigSave;
TRUNCATE TABLE dbo.ConfigCAS;
TRUNCATE TABLE dbo.ConfigCASSave;

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

Рекомендации по предотвращению проблемы

Чтобы избежать подобных ситуаций в будущем, придерживайтесь следующих правил:

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

Помните, что в РИБ самое главное — это целостность метаданных между узлами. Если стандартный обмен не помогает, принудительная перезагрузка через *.cf файл в отвязанном узле является наиболее надежным способом восстановления идентичности конфигураций.