Динамическое обновление конфигурации в среде разработчиков 1С часто называют «демоническим». Этот термин возник не на пустом месте: несмотря на кажущееся удобство внесения изменений без выгона пользователей, этот механизм таит в себе серьезные угрозы для стабильности информационной базы. В рамках данной статьи мы подробно разберем технические нюансы этого процесса, проанализируем возникающие ошибки и выработаем безопасную стратегию администрирования системы.
Для начала выясним, что происходит «под капотом» SQL-сервера, когда мы нажимаем кнопку подтверждения динамического обновления. Платформа 1С:Предприятие не заменяет основную конфигурацию в таблице Config мгновенно. Вместо этого она создает набор новых записей с особыми идентификаторами. Рассмотрим основные этапы этого процесса:
Именно на третьем этапе кроется главная опасность. Проанализируем ситуацию: если в одном из модулей была изменена экспортная процедура (например, добавился новый параметр), а клиентский сеанс еще использует старую версию формы, вызывающую эту процедуру, возникает критическое несоответствие. Рассмотрим типичный пример ошибки:
// Было в общем модуле:
Процедура РассчитатьСкидку(Сумма) Экспорт
// Стало после обновления:
Процедура РассчитатьСкидку(Сумма, ТипЦен) Экспорт
В этом случае пользователь, который не перезашел в программу, получит ошибку «Количество фактических параметров не совпадает с количеством формальных». Это происходит потому, что на сервере уже работает новый код, а на клиенте — старый кэш метаданных.
Одной из наиболее часто встречающихся проблем после динамического обновления является инвалидация серверного кэша. Ваши изменения могут «застрять» и не применяться к части пользователей. Выясним основные причины сбоев:
rphost может удерживать старые версии модулей в своей памяти. В таких случаях изменения не видны даже после перезапуска клиента.AppData хранят старые описания форм и макетов, что ведет к непредсказуемому поведению интерфейса.При использовании РИБ динамическое обновление является категорически недопустимым приемом. Разберем, почему это происходит. В РИБ синхронизация конфигурации завязана на номера сообщений обмена. Когда в главном узле выполняется динамическое обновление, создается промежуточное состояние. Периферийный узел при получении такого изменения часто входит в ступор: «Конфигурация базы данных не соответствует версии в главном узле».
Если вы столкнулись с такой ситуацией в РИБ, обычное «принятие изменений» может не сработать. В ряде случаев приходится прибегать к следующим шагам:
.cf, выгруженный из главного узла.Несмотря на все риски, существуют сценарии «форс-мажора», когда простой системы обходится дороже, чем риск сбоя. Рассмотрим пример с «черной пятницей» в крупном ритейле. Если в расчетном механизме скидок обнаружена критическая ошибка, а в базе работают более 500 пользователей и подключено технологическое оборудование (например, станки ЧПУ, получающие данные из 1С), выгонять всех на 30 минут может быть невозможно.
В таких случаях допустимо внесение изменений через расширения. Расширения подключаются в режиме предприятия и хранятся в отдельной таблице ConfigCAS. Это значительно безопаснее, так как их проще отключить в случае сбоя. Посмотрим на пример кода, который можно быстро внедрить через расширение для исправления логики префиксации без изменения основной конфигурации:
&После("ПриПолученииНомераНаПечать")
Процедура ПР_ПриПолученииНомераНаПечать(НомерОбъекта, СтандартнаяОбработка, УдалитьПрефиксИнформационнойБазы, УдалитьПользовательскийПрефикс)
Если СтандартнаяОбработка И СтрНачинаетсяС(НомерОбъекта, "СФЗК-") Тогда
НомерОбъекта = ОбщегоНазначенияБПВызовСервера.ПолучитьНомерБП20(НомерОбъекта, Истина);
СтандартнаяОбработка = Ложь;
КонецЕсли;
КонецПроцедуры
Такой подход позволяет изолировать изменения и избежать «загрязнения» основной таблицы Config.
Если вы все же вынуждены были прибегнуть к динамическому обновлению, крайне важно при первой же возможности провести полную фиксацию изменений. Проанализируем алгоритм действий опытного администратора:
Это действие заставит платформу «схлопнуть» все временные записи в таблице Config, очистить мусор и привести структуру базы данных в актуальное, целостное состояние. Это действие является критически важным для предотвращения накопления ошибок в будущем.
Начиная с современных версий платформы 8.3 (8.3.15 и выше), разработчики 1С предложили гораздо более надежный механизм — обновление конфигурации базы данных в фоновом режиме. Рассмотрим его преимущества:
В отличие от динамического обновления, фоновое обновление выполняет полноценную реструктуризацию (даже если вы добавили новые реквизиты) параллельно работе пользователей. Система подготавливает новую версию базы во временных таблицах, не мешая текущим сеансам. Монопольный режим требуется только в самом конце процесса для фиксации изменений, и обычно он длится от нескольких секунд до пары минут.
Резюмируем: динамическое обновление — это мощный, но опасный инструмент. Стоимость простоя в случае сбоя может включать в себя часы работы по восстановлению таблиц SQL, чистку кэша у сотен пользователей и ручную синхронизацию данных. Используйте внешние отчеты и обработки для изменения печатных форм, применяйте расширения для быстрой правки логики, а для серьезных изменений структуры всегда планируйте монопольный доступ или используйте механизмы фонового обновления платформы.