При работе с крупными конфигурациями, такими как 1С:ERP, разработчики часто сталкиваются с проблемой: при попытке подключить копию базы к новому хранилищу процесс надолго зависает на этапе "Формирование снимка конфигурации". При этом на сервере хранилища один из процессов (crserver) может загружать одно ядро процессора на 100%, но подключение так и не завершается, даже спустя много часов. Давайте разберемся, почему это происходит и как решить эту проблему.
Проанализируем ситуацию. Проблема чаще всего возникает не из-за сетевых ошибок или слабого "железа", а из-за внутреннего состояния самой конфигурации, из которой создается хранилище. Накопленные ошибки метаданных или особенности механизма поддержки могут приводить к зацикливанию или нештатному поведению при создании первоначального снимка. Наиболее эффективным решением является "очистка" конфигурации перед созданием хранилища.
Прежде чем переходить к сложным методам, убедимся, что мы исключили базовые проблемы. Эти шаги редко решают именно эту проблему, но их стоит выполнить для полноты картины.
Если эти действия не принесли результата, скорее всего, проблема в самой конфигурации. Перейдем к проверенному алгоритму решения.
Этот метод основан на том, чтобы избавиться от накопленного "мусора" в метаданных конфигурации путем ее выгрузки и загрузки в новую, чистую базу. Разберем по шагам, как это сделать.
Выгрузка конфигурации в файл. Зайдите в конфигуратор основной (боевой) базы, из которой планируется создать хранилище. Выполните команду Конфигурация -> Сохранить конфигурацию в файл... и сохраните ее в файл с расширением .cf.
Создание новой информационной базы. Создайте новую, пустую информационную базу без конфигурации.
Загрузка конфигурации из файла. Откройте конфигуратор новой пустой базы и загрузите в нее ранее сохраненный .cf файл через меню Конфигурация -> Загрузить конфигурацию из файла....
Создание локального файлового хранилища. Это ключевой шаг. Из этой "чистой" базы создайте новое хранилище конфигурации (Конфигурация -> Хранилище конфигурации -> Создать хранилище...). Важно создать его как локальное (файловое), например, в папке на диске C:\NewRepo. После создания хранилища не подключайте к нему эту тестовую базу.
Подключение основной базы. Теперь откройте конфигуратор основной (боевой) базы и подключите ее к только что созданному локальному файловому хранилищу (C:\NewRepo). Этот процесс должен пройти значительно быстрее.
Подключение копий. После успешного подключения основной базы подключите к этому же локальному хранилищу все остальные копии для разработки.
Перенос хранилища на сервер. Скопируйте содержимое папки C:\NewRepo на сервер, где должен работать сервис хранилища (crserver), в его рабочий каталог.
Смена пути к хранилищу. В конфигураторах всех подключенных баз (основной и копий) измените адрес хранилища с локального пути на сетевой, например, tcp://your-server-name/repo-name. Платформа корректно обработает смену адреса, и вы сможете продолжить работу в штатном режиме.
Этот алгоритм позволяет обойти проблемы, связанные с внутренним состоянием исходной базы, и успешно создать рабочее хранилище для большой и сложной конфигурации.
Если основной метод по какой-то причине не подходит, можно рассмотреть и другие варианты, которые могут помочь в некоторых ситуациях.
Использование протокола HTTP. Вместо прямого подключения по протоколу TCP можно опубликовать хранилище на веб-сервере (IIS или Apache) и подключаться к нему по HTTP/HTTPS. Иногда это помогает обойти проблемы, связанные с сетевыми фильтрами или особенностями прохождения TCP-трафика.
Проверка флагов поддержки. Как показала практика, проблема может быть связана с объектами, находящимися на поддержке. В одном из случаев помогла манипуляция с флагами: рекурсивная установка для всей конфигурации статуса "Редактируется с сохранением поддержки" и последующий возврат в состояние "Объект поставщика редактируется с сохранением поддержки". Это очень трудоемкий процесс, но он указывает на глубинную причину проблемы.
Переход на Git. Стоит также отметить, что для командной разработки все чаще используются альтернативные системы контроля версий, такие как Git. Они лишены многих проблем, присущих штатному хранилищу 1С, и предлагают более мощные механизмы ветвления и слияния. Существуют решения, которые позволяют быстро анализировать изменения из git-репозитория прямо в 1С, что делает переход на эту систему более комфортным.