Разработка в среде 1С:Предприятие 8.3 при использовании Хранилища конфигурации — это стандарт индустрии для командной работы. Однако многие разработчики сталкиваются с крайне неприятной ситуацией: после захвата объекта, внесения правок и выполнения обновления конфигурации базы данных, внесенные изменения внезапно исчезают. Кажется, что Конфигуратор «откатил» код к предыдущему состоянию. Рассмотрим подробнее, почему это происходит, как работает механизм «демонического» (динамического) обновления и что делать, чтобы не потерять результаты своей работы.
Проанализируем ситуацию, описанную в теме. Разработчик захватил общий модуль, внес изменения, а в это время другой участник команды произвел захват корня хранилища. При попытке обновить конфигурацию происходит рассинхронизация. Выясним причину этого явления. В системе 1С при динамическом обновлении возникает так называемое «третье состояние» метаданных. Существуют три версии одного и того же объекта:
ConfigSave: Временная копия, которая создается сервером 1С при динамическом обновлении для тех сеансов, которые еще не перезапустились.Когда происходит захват корня хранилища, платформа инициирует проверку всей структуры метаданных. Если в этот момент выполняется динамическое обновление, индексы объектов в локальном кэше могут перемешаться. В результате Конфигуратор ошибочно считает, что ваша локальная копия устарела, и принудительно замещает ее текстом из кэша, который еще не содержит новых правок.
Термин «демоническое обновление» прочно закрепился в среде 1С за механизмом динамического обновления конфигурации БД без выгона пользователей. Разберем по шагам, почему его использование в процессе активной разработки с хранилищем крайне рискованно:
Во-первых, динамическое обновление не изменяет основную таблицу Config, а записывает изменения в ConfigSave. Пока все пользователи не перезапустят свои сеансы, система находится в подвешенном состоянии. Во-вторых, при работе с Хранилищем конфигурация постоянно сравнивает версии. Если вы обновили базу динамически, а затем другой программист поместил изменения в хранилище, ваш локальный кэш может войти в ступор, не понимая, какая версия является приоритетной.
Важный момент: В версиях платформы 8.3.10, 8.3.11 и 8.3.12 был зафиксирован баг, при котором динамическое обновление могло привести к частичной потере ссылочной целостности в кэше метаданных, что и вызывает эффект «пропажи кода».
Если вы обнаружили, что ваши правки исчезли из открытого модуля, первым делом не нажимайте кнопку «Сохранить» и не делайте «Поместить в хранилище». Это может окончательно перезаписать верную версию в хранилище пустым или старым кодом. Посмотрим на алгоритм спасения данных:
Самый простой и эффективный способ — удалить файлы кэша, где хранятся скомпилированные образы метаданных. Закройте все сеансы 1С и Конфигуратор, затем перейдите в папки:
%AppData%\Local\1C\1Cv8\%AppData%\Roaming\1C\1Cv8\Удалите все папки с длинными именами-идентификаторами (например, eb34a1...). После этого при запуске 1С заново скачает актуальные метаданные с сервера.
Иногда проблема кроется в локальной копии базы хранилища. Она находится в подпапке snccache внутри профиля пользователя. Найдите там файл v8system.lst и удалите его вместе с содержимым папки. Это заставит Конфигуратор заново синхронизироваться с хранилищем при следующем подключении.
Для профилактики проблем с кэшем запросов к серверу, добавим в параметры запуска информационной базы специальный ключ. Рассмотрим пример настройки:
/ClearCache.Этот ключ заставляет систему очищать кэш клиент-серверных вызовов при каждом запуске, что минимизирует риск увидеть «старый» код.
В критических ситуациях, когда динамическое обновление «зависло» и база ведет себя неадекватно (например, не дает зайти в Конфигуратор), может потребоваться вмешательство на уровне SQL. Проанализируем безопасный способ очистки таблиц конфигурации. Внимание: делайте бэкап перед любыми операциями с SQL!
Для удаления «зависшего» динамического обновления можно выполнить следующий запрос в консоли SQL:
-- Удаляем временную конфигурацию
DELETE FROM ConfigSave;
-- Сбрасываем флаг динамического обновления
DELETE FROM Config WHERE FileName = 'commit';
Эти команды принудительно заставят сервер 1С считать, что никакой подготовки к обновлению не ведется, и позволят выполнить полноценное («монопольное») обновление конфигурации базы данных.
Чтобы избежать подобных «глюков» в будущем, придерживайтесь следующих правил командной разработки:
Подводя итог, можно сказать, что описанная ситуация — это не фича, а известная особенность взаимодействия механизмов кэширования и динамического обновления. Соблюдение гигиены разработки и регулярная очистка кэша позволят вам сохранить нервы и результаты своего труда.