Каждый разработчик 1С рано или поздно сталкивается с ситуацией, когда необходимо быстро внести незначительное исправление в программный код работающей базы данных, не прерывая сеансы пользователей. В платформе 1С для этого предусмотрен механизм динамического обновления. Однако бывают случаи, когда даже при самом незначительном изменении (например, добавлении или удалении пробела в модуле) система наотрез отказывается обновляться динамически. Вместо привычного диалогового окна с предложением обновить конфигурацию базы данных динамически, платформа выводит жесткое предупреждение: «Активны сеансы. Вариант только завершить работу или перезапуститься».
В этой статье мы подробно проанализируем, почему возникает такое поведение платформы 1С:Предприятие 8.2 (особенно на релизах семейства 8.2.19.130), разберем внутренние механизмы блокировки динамического обновления и рассмотрим пошаговые инструкции по восстановлению штатной работы конфигуратора.
---
Почему платформа блокирует динамическое обновление?
В нормальном режиме работы система разрешает динамическое обновление только тогда, когда внесенные изменения затрагивают исключительно исполняемый код (модули), экранные формы, интерфейсы или макеты. Эти элементы не влияют на физическую структуру таблиц СУБД. Если же изменения затрагивают метаданные (добавление реквизитов, справочников, изменение типов данных), требуется реструктуризация базы данных, выполнение которой невозможно при наличии активных пользователей.
Если вы изменили всего один символ в модуле, а система всё равно требует монопольного доступа, это означает, что платформа по какой-то причине считает структуру базы данных измененной. Выделим основные технические причины этого сбоя:
Незавершенный переход после конвертации базы (с версии 8.1 на 8.2). При конвертации информационной базы между мажорными версиями платформы меняются внутренние форматы хранения метаданных. Если после конвертации базы не было выполнено ни одного полного монопольного обновления (с реструктуризацией таблиц), база данных зависает в «переходном» состоянии. Любое последующее изменение кода будет восприниматься платформой как необходимость завершить глобальное обновление всей структуры данных.
«Очередь» невыполненных изменений метаданных. Если ранее в конфигураторе были созданы новые объекты метаданных (справочники, документы, регистры), но база так и не была обновлена монопольно, эти изменения сохраняются в промежуточном буфере. Любая ваша последующая правка кода (даже банальный пробел) «встает в очередь» за этими структурными изменениями. Пока вы не примените все накопленные изменения метаданных в монопольном режиме, динамическое обновление для кода будет заблокировано.
Сбой механизма предыдущего динамического обновления. Если в процессе прошлого динамического обновления произошел сетевой сбой, зависание сессии разработчика или аварийное завершение работы конфигуратора, внутренние таблицы регистрации изменений могут остаться в некорректном (рассинхронизированном) состоянии.
Рассинхронизация локального кэша метаданных. Платформа 1С активно кэширует структуру метаданных на компьютерах пользователей и сервере приложений. Сбои в кэше приводят к тому, что конфигуратор начинает видеть различия между основной конфигурацией и конфигурацией базы данных там, где их на самом деле нет.
---
Пошаговые решения для восстановления динамического обновления
Рассмотрим подробно каждый способ решения данной проблемы — от самых простых действий в конфигураторе до низкоуровневых манипуляций на сервере СУБД.
Решение 1. Полное монопольное обновление конфигурации
В большинстве случаев проблема решается проведением штатной процедуры обновления базы данных в монопольном режиме. Это особенно актуально, если база была недавно сконвертирована из версии 8.1.
Выполним следующие действия по шагам:
Согласуем с пользователями время проведения технических работ и дождемся окончания рабочего дня.
Полностью завершим все активные сеансы пользователей. Если база работает в терминальном режиме (RDP), обязательно проверим диспетчер задач на сервере: сессии пользователей не должны находиться в состоянии «Disconnected» (отключен), так как процесс 1cv8.exe в этом режиме продолжает удерживать соединения и блокировать базу.
Если база клиент-серверная, зайдем в консоль администрирования серверов 1С и убедимся, что в списке соединений и сеансов отсутствуют фоновые задания, регламентные процедуры и зависшие подключения. При необходимости завершим их принудительно.
Запустим конфигуратор 1С монопольно.
Выполним команду главного меню Конфигурация -> Обновить конфигурацию базы данных (или нажмем клавишу F7).
Дождемся окончания процесса реструктуризации таблиц. После успешного завершения запустим базу в пользовательском режиме один раз, чтобы завершить все внутренние обработчики обновления.
После проведения этой процедуры база данных синхронизирует свою внутреннюю структуру, и последующие минорные изменения кода снова можно будет вносить динамически.
Решение 2. Сброс изменений и возврат к конфигурации БД
Если вы хотите убедиться, что в конфигурации действительно не зависли скрытые изменения метаданных, выполним операцию отката к исходному состоянию:
Откроем конфигуратор нашей информационной базы.
Выберем пункт меню Конфигурация -> Конфигурация базы данных -> Вернуться к конфигурации БД. Системные метаданные основной конфигурации будут полностью замещены стабильной версией из базы данных.
Сохраним изменения.
Теперь внесем тестовое изменение в любой модуль (например, добавим пробел в неиспользуемом месте кода).
Попробуем выполнить обновление базы данных. Если диалоговое окно динамического обновления появилось — проблема успешно решена.
Решение 3. Сравнение основной конфигурации и конфигурации БД через CF-файл
Иногда визуально кажется, что изменений в метаданных нет, но платформа упорно видит скрытые различия. Чтобы точно проанализировать разницу, выполним сравнение файлов конфигураций:
В конфигураторе выгрузим текущую основную конфигурацию в файл. Для этого выберем Конфигурация -> Сохранить конфигурацию в файл... и укажем путь для сохранения (получим файл с расширением .cf).
Затем сделаем откат к конфигурации базы данных, как описано в Решении 2 (Конфигурация -> Конфигурация базы данных -> Вернуться к конфигурации БД).
Выполним сравнение: выберем пункт меню Конфигурация -> Сравнить, объединить с конфигурацией из файла... и укажем ранее сохраненный .cf-файл.
В открывшемся окне сравнения мы наглядно увидим дерево различий. Если там присутствуют измененные или добавленные объекты метаданных, это и была причина блокировки динамического обновления. Если же различий нет (или там только модули), мы можем безопасно объединить конфигурации и продолжить работу.
Решение 4. Очистка кэша метаданных 1С
Если монопольное обновление выполнено, но при попытке динамического изменения платформа всё равно ведет себя некорректно, велика вероятность повреждения локального кэша метаданных на рабочем компьютере разработчика или на терминальном сервере.
Для устранения этой проблемы очистим кэш по следующему алгоритму:
Полностью закроем все запущенные окна 1С:Предприятия и Конфигуратора.
Откроем проводник Windows и перейдем по следующим путям (для операционных систем Windows 7 / 10 / Server 2008 / Server 2012 и выше):
%userprofile%\AppData\Local\1C\1Cv82
%userprofile%\AppData\Roaming\1C\1Cv82
Внутри этих директорий мы увидим множество папок с длинными шестнадцатеричными именами типа 8f1b626d-2391-4c28-912b-7cfa57c2a715. Это и есть локальный кэш баз данных. Полностью удалим эти папки. При следующем запуске 1С платформа автоматически пересоздаст кэш с актуальными и чистыми метаданными.
Альтернативный быстрый способ очистки кэша для конкретной базы — удалить её из списка баз в окне запуска 1С, нажать кнопку «ОК», а затем добавить эту же базу заново. При этом для базы сгенерируется новый уникальный идентификатор (UID), и старый поврежденный кэш больше не будет использоваться.
Решение 5. Очистка таблицы ConfigSave на уровне СУБД (для клиент-серверного варианта)
В редких случаях, когда сбой динамического обновления произошел на уровне СУБД (MS SQL Server или PostgreSQL), конфигурация базы данных может «зависнуть» в СУБД в таблице временного хранения изменений. В Конфигураторе при этом могут возникать неисправимые ошибки.
Важное предупреждение: Любые операции на уровне СУБД должны выполняться только квалифицированными специалистами и только после создания полной резервной копии базы данных (бэкапа)!
Проанализируем структуру СУБД: временные несохраненные изменения конфигурации хранятся в таблице ConfigSave. Если мы гарантированно хотим сбросить незавершенное динамическое обновление и вернуть конфигуратор к стабильному состоянию конфигурации базы данных, мы можем очистить эту таблицу.
Для этого в MS SQL Server Management Studio выполним следующий SQL-запрос:
-- Перед выполнением обязательно убедитесь, что сделана резервная копия базы данных!
USE [Имя_Вашей_Базы_Данных];
GO
-- Очищаем таблицу временных сохранений конфигурации
TRUNCATE TABLE [dbo].[ConfigSave];
GO
После очистки таблицы ConfigSave запустим Конфигуратор. Он откроется в состоянии, полностью соответствующем текущей конфигурации базы данных, а все «зависшие» изменения будут сброшены. После этого механизм динамического обновления снова станет доступен.
---
Риски частого использования динамического обновления
В сообществе разработчиков 1С динамическое обновление часто называют «демоническим» из-за его потенциальной нестабильности. Мы крайне рекомендуем не злоупотреблять этим механизмом в повседневной работе по следующим причинам:
Ошибка формата потока. При частом наложении динамических обновлений друг на друга структура метаданных в базе данных замусоривается. Это может привести к критической ошибке «Ошибка формата потока», после которой база перестанет запускаться как в пользовательском режиме, так и в режиме конфигуратора. Восстановление базы после такого сбоя потребует утилиты chdbfl.exe или ручного исправления таблиц базы данных.
Разные версии кода у пользователей. Пользователи, которые работали в программе в момент динамического обновления, продолжают исполнять старый код, хранящийся в их локальной оперативной памяти. Новые пользователи, зашедшие в систему, начинают работать с новым кодом. Это может приводить к рассинхронизации данных, когда старый и новый код одновременно выполняют транзакции в базе данных.
Проблемы с фоновыми заданиями. Если в базе активно работают фоновые или регламентные задания, динамическое обновление может прервать их выполнение или вызвать непредсказуемые ошибки СУБД (например, ошибки обращения к временным таблицам).
Таким образом, динамическое обновление — это инструмент быстрого реагирования для исправления критических ошибок («горящих фиксов»), но регулярное плановое обновление конфигурации всегда следует выполнять в монопольном режиме с полным отключением пользователей.