← На главную

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

Причины возникновения рассинхронизации версий

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

1. Динамическое обновление информационной базы разработчика. Если при помещении изменений или после их получения применяется динамическое обновление (обновление конфигурации базы данных без перезапуска сеансов), во внутренних таблицах Config и ConfigSave нарушается соответствие версий. Конфигуратор ошибочно считает локальный снимок объекта актуальным и при выполнении команды «Получить из хранилища» просто пропускает его загрузку.
2. Зависание или повреждение специализированного кэша хранилища. Платформа 1С хранит локальные кэшированные снимки и хэши версий хранилища в отдельном каталоге cfgrepo. Если этот кэш повреждается, клиентский конфигуратор перестает запрашивать обновленные данные с сервера хранилища.
3. Проблемы сетевого доступа к файловому хранилищу. При размещении файла 1cv8ddb.1cd в общей сетевой папке (SMB) блокировки операционной системы или кратковременные сетевые сбои могут приводить к неполной фиксации транзакций и искажению индексов хранилища.
4. Разные релизы платформы 1С у разработчиков. Работа с одним хранилищем с разных версий платформы может вызывать сбои при сериализации метаданных.

Способ 1. Монопольное обновление конфигурации базы данных

Разберем базовое решение проблемы, если один из разработчиков обновлял рабочую базу динамически:

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

Способ 2. Очистка специализированного кэша хранилища

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

1. Закроем все запущенные конфигураторы и сеансы 1С на рабочих местах разработчиков.
2. Перейдем в каталог локальных данных пользователя Windows: %APPDATA%\1C\1Cv8\ (а также %LOCALAPPDATA%\1C\1Cv8\).
3. Найдем папку с уникальным идентификатором информационной базы и перейдем во вложенный каталог cfgrepo\cache.
4. Удалим содержимое каталога cache или всю папку cfgrepo. При следующем подключении к хранилищу платформа заново выгрузит актуальный снимок метаданных.

Способ 3. Принудительное обновление объекта через фиктивный захват

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

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

Способ 4. Сравнение и объединение с конфигурацией хранилища

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

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

Способ 5. Администрирование и проверка целостности хранилища

Если ошибки продолжают возникать, проверим целостность самого файла хранилища:

1. Откроем меню «Конфигурация — Хранилище конфигурации — Администрирование хранилища» под учетной записью с административными правами.
2. Нажмем кнопку «Проверить» для поиска логических ошибок в структуре данных хранилища.
3. После успешной проверки выполним команду «Оптимизировать» для сжатия таблиц и перестроения индексов.
4. Важно: не используйте внешнюю утилиту chdbfl.exe для файла хранилища конфигураций 1cv8ddb.1cd, так как это может безвозвратно повредить цепочки версий.

Способ 6. Полное переподключение базы к хранилищу

В случаях глубокого повреждения снимка конфигурации выполним переподключение базы данных:

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

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

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

1. Полный запрет динамического обновления в базах, подключенных к хранилищу конфигурации. Любые обновления базы данных должны выполняться только в стандартном монопольном режиме.
2. Использование сервера хранилища crserver вместо прямого доступа по локальной сети через общую папку. Работа по протоколу TCP/IP через сервер хранилища защищает базу от сбоев файловых блокировок Windows.
3. Использование одинаковой версии платформы 1С всеми участниками команды разработки.