Ситуация, когда после нескольких успешных динамических обновлений внесенный код внезапно исчезает после перезапуска Конфигуратора, знакома многим администраторам и разработчикам файловых баз. Проблема выглядит мистически: вы сохраняете изменения, обновляете конфигурацию базы данных, проверяете работу — всё отлично. Но на четвертый или пятый раз Конфигуратор будто «откатывается» назад, и весь новый код пропадает. Давайте разберем этот механизм детально и выясним, как с этим бороться.
Для начала проанализируем, как 1С вообще обрабатывает изменения. В системе существует не одна, а сразу три конфигурации:
В норме при обычном (монопольном) обновлении основная конфигурация полностью заменяет конфигурацию базы данных в таблице Config. Однако при динамическом обновлении платформа не заменяет данные целиком. Вместо этого она создает в таблице Config специальные записи — инкременты (дополнительные слои). Это позволяет работающим пользователям продолжать использовать «старую» версию из своей памяти, в то время как новые сеансы начинают подтягивать «новую» версию.
Суть проблемы: В файловом варианте базы данных (файл .1CD) механизм сопоставления этих слоев крайне чувствителен к количеству изменений. Когда таких инкрементов накапливается слишком много (как в вашем случае — на 4-й раз), транзакция фиксации изменений может пройти в памяти Конфигуратора, но не зафиксироваться физически в файле базы из-за внутренних блокировок или ошибок кэширования метаданных. В итоге вы видите изменения, пока открыта сессия Конфигуратора, но после его перезапуска он считывает реальное состояние таблицы Config, где транзакция «откатилась».
Рассмотрим подробнее, почему Конфигуратор вводит нас в заблуждение. У него есть собственный локальный кэш (папки ConfigSave и другие структуры в профиле пользователя). Когда вы вносите изменения, они сначала попадают во временные таблицы. При динамическом обновлении платформа должна перенести их в основную структуру .1CD.
Поскольку файловая база работает через механизм файловых блокировок ОС, а не через полноценный SQL-сервер, любая сетевая задержка (если база на сетевом диске) или активность антивируса в момент записи может привести к тому, что 1С «считает» запись успешной, но фактически индекс таблицы Config повреждается или не обновляется. Это объясняет, почему только монопольное обновление помогает: оно принудительно пересобирает таблицу конфигурации, удаляя все динамические «хвосты».
Если ситуация критическая и выгнать всех пользователей прямо сейчас невозможно, но изменения «зависли» и не сохраняются, проанализируем технический прием, который часто помогает «протолкнуть» метаданные:
Сохранить конфигурацию в файл... -> .cf)..cf файл обратно через Сравнить, объединить с конфигурацией из файла или Загрузить конфигурацию из файла.Этот метод заставляет платформу пересчитать контрольные суммы и часто позволяет корректно завершить транзакцию записи в таблицу Config, обходя ошибки локального кэша.
Выясним причину, почему именно на файловых базах динамическое обновление считается «хождением по лезвию ножа». При работе через протоколы SMB/CIFS (сетевые папки) стабильность файловых транзакций снижается. При динамическом обновлении создается множество временных файлов с именами вида v18_.... Если антивирус на сервере или на вашей рабочей станции решит проверить этот файл в момент его фиксации, 1С получит отказ в доступе на миллисекунду, что приведет к рассинхронизации основной и динамической конфигураций.
Рекомендация: Для файловых баз крайне желательно выполнять любые обновления (даже динамические) локально на том сервере, где физически лежит файл .1CD, чтобы минимизировать влияние сетевых протоколов.
В структуре базы данных 1С есть служебная информация, которая хранит состояние «в процессе обновления». Если одно из ваших предыдущих динамических обновлений завершилось с микро-сбоем (невидимым для глаза), этот флаг может застрять в промежуточном состоянии. Все последующие попытки записи будут накладываться на эту ошибку.
Проанализируем ситуацию: на 4-й раз база данных просто «отказывается» принимать новые слои, так как исчерпан лимит корректных записей в цепочке метаданных. Единственный надежный способ очистить эти флаги — это запуск Конфигуратора в монопольном режиме и выполнение полного обновления. Это полностью очистит таблицу Config от накопившегося «мусора» инкрементальных обновлений.
Подводя итог, можно сказать, что ваше наблюдение про «3 раза» — это не ограничение платформы, а симптом деградации структуры метаданных в конкретном файле базы. Чтобы избежать потери данных и порчи базы, рекомендуем придерживаться следующих правил:
%AppData%\1C\1cv8).Тестирование и исправление с галочкой Проверка логической целостности конфигурации..1CD постоянно дорабатываются, и вероятность таких сбоев снижается.Помните, что файловая база не имеет таких механизмов обеспечения транзакционности, как SQL-сервер, поэтому любая работа с метаданными в «горячем» режиме всегда несет риск полной потери работоспособности базы.