← На главную

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

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

Почему возникает ошибка хеш версии файла конфигурации

Проанализируем внутренние механизмы платформы. Каждая конфигурация и расширение внутри базы данных 1С представляют собой совокупность сериализованных потоков данных. В служебных таблицах СУБД CONFIG, CONFIGSAVE, а также в служебном файле configinfo хранятся контрольные хеш-суммы каждого блока метаданных. Несоответствие этих хешей провоцируется следующими факторами:

1. Рассинхронизация хеш-сумм внутренних потоков метаданных: хеш полученного из хранилища фрагмента объекта не сходится с контрольным значением, зафиксированным в описании версии расширения.
2. Повреждение локального кэша хранилища конфигурации: при обрыве сетевого соединения или аварийном закрытии Конфигуратора локальный кэш версий повреждается, и платформа подставляет некорректный блок данных.
3. Разница в версиях технологической платформы: если разработчики в одной команде используют разные релизы 1С (например, один работает на сборке 8.3.22, а другой на 8.3.24), механизмы сериализации и расчета хеш-сумм могут различаться, что ломает валидацию при помещении изменений в общее хранилище.
4. Коллизии заимствованных объектов: изменение метаданных в основной конфигурации часто приводит к рассинхронизации структуры связанных объектов, заимствованных в расширение.

Основное решение: исправление через файл выгрузки расширения (CFE)

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

Разберем процесс по шагам:

1. Сохранение эталонной версии: открываем базу, в которой ошибка не возникает и которая не отключалась от хранилища. Переходим в меню Конфигурация -> Расширения конфигурации, выбираем нужное расширение и нажимаем Действия -> Сохранить конфигурацию в файл.... Сохраняем расширение в файл с расширением .cfe.
2. Подготовка проблемной базы: запускаем Конфигуратор проблемной информационной базы. Отключаем расширение от хранилища (Хранилище -> Отключиться от хранилища).
3. Загрузка конфигурации из файла: в проблемной базе через список расширений загружаем сохраненный ранее файл (Действия -> Загрузить конфигурацию из файла...) и выбираем наш .cfe.
4. Фиксация структуры: обновляем конфигурацию базы данных по клавише F7. На этом этапе ошибка хеша не возникает, так как структура загружена напрямую из корректного бинарного файла в обход сбойного кэша хранилища.
5. Повторное подключение к хранилищу: подключаем расширение обратно к хранилищу. Важно: не нажимаем обновление конфигурации базы данных на этом шаге!
6. Полный захват расширения: захватываем корень расширения в хранилище целиком (все объекты должны быть захвачены).
7. Сброс к рабочей конфигурации: в командной панели окна расширения выполняем команду Конфигурация -> Конфигурация базы данных -> Вернуться к конфигурации БД. Это действие приводит структуру редактируемой конфигурации в строгое соответствие с работающей базой данных и пересчитывает служебные хеши.
8. Фиксация исправлений в хранилище: помещаем расширение конфигурации обратно в хранилище.

После выполнения этих действий контрольные хеши в хранилище обновляются, и ошибка перестает воспроизводиться на всех остальных клиентских базах.

Альтернативные способы устранения неполадки

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

1. Очистка локального кэша хранилища

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

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

2. Актуализация свойств заимствованных объектов

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

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

3. Очистка таблицы CONFIGSAVE в клиент-серверном варианте

В клиент-серверных базах (MS SQL Server, PostgreSQL) незафиксированные изменения сеанса конфигуратора блокируются во временной таблице. Если штатный откат в Конфигураторе завершается аварией, на предварительно созданной резервной копии базы данных средствами СУБД можно выполнить очистку таблицы CONFIGSAVE, после чего заново открыть Конфигуратор и повторить получение версии.

4. Проверка целостности файла хранилища

Если хранилище расположено в общей сетевой папке (файловый вариант), файл 1cv8ddb.1cd мог получить повреждения на уровне файловой системы из-за сетевого сбоя. В таком случае завершаем все сеансы работы с хранилищем и запускаем штатную утилиту тестирования chdbfl.exe (находится в папке bin установленной платформы 1С) для файла хранилища.

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

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

1. Строго одинаковые версии платформы: все программисты, работающие с единым хранилищем, должны использовать один и тот же номер сборки технологической платформы.
2. Отказ от динамического обновления: регулярное применение «демонического» (динамического) обновления базы данных накапливает ошибки в служебных таблицах метаданных. Все обновления структуры данных должны выполняться в монопольном режиме.
3. Регулярное резервное копирование: создаем регулярные копии файлов хранилищ конфигураций и расширений (1cv8ddb.1cd), а также сохраняем эталонные версии конфигураций в файлы .cf и .cfe перед масштабными слияниями веток разработки.