Каждый разработчик и администратор 1С рано или поздно сталкивается с крайне неприятной ситуацией: в код или схему компоновки данных внешнего отчета вносятся исправления, файл сохраняется, но при открытии в режиме «1С:Предприятие» пользователь видит старую версию. Создается полное ощущение, что платформа игнорирует новый файл и упрямо запускает предыдущую версию. Иногда помогает только переименование файла или самого объекта отчета в конфигураторе. Особенно часто эта проблема проявляется при работе через терминальный доступ (RDP) в конфигурациях на управляемых формах, таких как Управление торговлей 11, ERP Управление предприятием или Комплексная автоматизация.
В этой статье мы подробно разберем, почему возникает этот неприятный эффект «застревания» старой версии, проанализируем внутренние механизмы платформы 1С и Библиотеки Стандартных Подсистем (БСП), а также выработаем пошаговые инструкции для решения этой проблемы без постоянного переименования файлов.
Основная причина, по которой изменения в макете СКД (Системе компоновки данных) не отображаются у пользователя — это логика работы хранилища настроек платформы 1С. Выясним, как устроен этот процесс изнутри.
При первом открытии отчета платформа 1С автоматически считывает его структуру и сохраняет настройки по умолчанию, а также пользовательские настройки в системные таблицы базы данных. При всех последующих открытиях этого же отчета платформа выполняет следующие действия:
Как решить эту проблему в режиме Предприятия:
Самый простой способ заставить 1С перечитать структуру из файла — это сбросить пользовательские настройки до заводских. Для этого в форме открытого отчета найдем кнопку «Еще», далее перейдем в меню «Установить стандартные настройки» (в некоторых интерфейсах это может быть путь «Все действия» ➔ «Стандартные настройки»). После выполнения этой команды платформа принудительно перезапишет кэш настроек актуальными данными из физического файла отчета.
Как решить эту проблему на уровне разработки в Конфигураторе:
Если мы ведем активную отладку отчета и не хотим заставлять пользователя постоянно сбрасывать настройки, выполним следующие действия:
ХранилищеВариантов. Если там указано стандартное хранилище, платформа будет агрессивно кэшировать настройки.Современные конфигурации 1С активно используют БСП для интеграции дополнительных отчетов и обработок. Здесь разработчика подстерегает неочевидная ловушка.
Представим ситуацию: наш внешний отчет уже зарегистрирован в справочнике ДополнительныеОтчетыИОбработки. Мы решили внести изменения в локальный файл отчета на своем компьютере и открываем его через стандартное меню Файл ➔ Открыть. К нашему удивлению, изменения не применились.
Проанализируем причину. При открытии внешнего файла БСП перехватывает это событие. Она анализирует имя объекта или его внутренние идентификаторы. Если система находит совпадение с отчетом, зарегистрированным в справочнике дополнительных обработок, она блокирует запуск локального файла и подсовывает пользователю версию отчета, хранящуюся внутри базы данных. Это сделано в целях безопасности и контроля версий, но очень сильно мешает процессу разработки.
Как обойти защиту БСП:
Иногда закрытие формы отчета и повторное открытие файла не приводят к обновлению исполняемого кода модулей. Разберем, почему это происходит.
Платформа 1С использует механизм подсчета ссылок для управления оперативной памятью (Garbage Collector). Объект отчета остается в ОЗУ сервера или клиента до тех пор, пока на него указывает хотя бы одна ссылка. Если в коде отчета допущена циклическая ссылка, объект зависает в памяти навсегда.
Посмотрим на пример опасного кода, который приводит к зависанию объекта в памяти:
// В модуле объекта внешнего отчета
Перем СсылкаНаФорму;
Процедура ИнициализироватьОтчет(ФормаПриемник) Экспорт
// Создаем прямую ссылку из объекта на форму
СсылкаНаФорму = ФормаПриемник;
КонецПроцедуры
В этом примере форма ссылается на отчет (через реквизит Отчет), а объект отчета хранит ссылку на форму в глобальной переменной модуля. При закрытии окна пользователем форма визуально исчезает с экрана, но фактически обе структуры остаются в оперативной памяти, так как ссылаются друг на друга. При повторном открытии файла платформа 1С обнаруживает «живой» объект в памяти и вместо чтения файла с диска повторно использует старый экземпляр вместе со старым кодом.
Чтобы избежать подобных проблем, всегда своевременно очищайте ссылки или передавайте контекст через параметры процедур без сохранения в переменные модуля объекта.
В сообщениях на форуме пользователи часто отмечают, что сбой стабильно воспроизводится именно при подключении по RDP. Это связано с особенностями работы файловой системы терминального сервера.
При запуске внешнего отчета платформа 1С распаковывает его бинарные данные в каталог временных файлов текущего пользователя. Путь к этому каталогу обычно выглядит так: %TEMP% или C:\Users\ИмяПользователя\AppData\Local\Temp\.
В условиях многопользовательской работы на терминальном сервере могут возникать следующие конфликты:
Рекомендации по настройке сервера для системного администратора:
%TEMP% при завершении сеанса пользователя (Logoff)./ClearCache. Этот параметр принудительно очищает кэш метаданных при каждом запуске системы, что предотвращает появление устаревших версий объектов.В процессе обсуждения проблемы пользователи часто упоминают сопутствующие сбои: появление пустых окон и критическую ошибку библиотеки 1clib после обновления конфигурации или расширений. Проанализируем природу этого явления.
Такое поведение — классический симптом повреждения динамического кэша конфигурации (так называемого DynamicalWorkCache). Сбой происходит из-за применения технологии «динамического обновления» (обновление конфигурации базы данных без выгона пользователей).
Когда администратор обновляет метаданные или расширения «на лету», сервер 1С пытается подменить работающие модули в памяти активных сеансов. Если у пользователя в этот момент была открыта форма изменяемого объекта, происходит рассинхронизация версий структуры метаданных. Кэш на клиенте ломается, что приводит к невозможности отрисовки интерфейса платформой, выдаче пустых окон и аварийному завершению работы процесса.
Как правильно устранять последствия динамического обновления:
1C:Enterprise Server Daemon, перейдите в каталог кластера (по умолчанию это папка srvinfo) и удалите содержимое папки snccntx, где хранятся сеансовые данные и кэш метаданных.%userprofile%\AppData\Local\1C\1Cv8\
%userprofile%\AppData\Roaming\1C\1Cv8\
Применяя эти системные подходы, мы навсегда избавимся от проблемы «зависания» старых версий отчетов и обеспечим стабильную, предсказуемую работу нашей системы 1С:Предприятие.