Зависание системы при открытии определенных форм — одна из самых коварных проблем, с которыми сталкивается администратор или программист 1С. Ситуация, когда у одного пользователя «крутится колесико», а у остальных всё работает штатно, часто ставит в тупик. Рассмотрим подробно причины возникновения подобных задержек в конфигурации 1С:Бухгалтерия предприятия 3.0 и разберем по шагам методы их устранения.
Прежде всего, проанализируем поведение системы. Если зависание происходит сразу после процедуры ПриСозданииНаСервере, это сигнализирует о том, что программный код модуля формы отработал успешно, и управление перешло к платформе для компоновки и отображения динамического списка. Именно в этот момент 1С формирует SQL-запрос к базе данных, учитывая все установленные отборы, сортировки и настройки прав доступа RLS.
Для начала воспользуемся встроенным инструментом Замер производительности. Рассмотрим, как это сделать:
Если замер показывает, что основное время тратится не на встроенный язык, а на ожидание ответа от сервера базы данных, значит, проблема кроется в структуре запроса или механизмах платформы.
Поскольку проблема воспроизводится у конкретного пользователя даже на разных рабочих станциях, а очистка локального кэша не дает результата, выясним причину в настройках, хранящихся непосредственно в информационной базе. Часто пользователи случайно устанавливают слишком сложные условия в «Условном оформлении» или выбирают неоптимальную сортировку.
Выполним процедуру сброса настроек формы:
РеализацияТоваровУслуг.Важно: Обратите особое внимание на «Условное оформление». Если пользователь настроил выделение цветом строк по условию, которое требует обращения к связанным таблицам (например, через несколько «точек» от основного объекта), динамический список будет тормозить при отрисовке каждой страницы данных.
Динамические списки в управляемых формах тесно интегрированы с механизмом полнотекстового поиска. Если индекс поиска поврежден или актуализируется в момент открытия формы, это может вызвать кратковременное или длительное зависание. Разберем, как проверить этот фактор:
Попробуем временно отключить полнотекстовый поиск для всей базы (через «Администрирование» — «Поддержка и обслуживание» — «Управление полнотекстовым поиском»). Если после этого форма открывается мгновенно, проблема найдена. В таком случае рекомендуется выполнить полную очистку и обновление индекса. В коде это можно инициировать следующим образом:
// Пример программного обновления индекса полнотекстового поиска
ПолнотекстовыйПоиск.ОчиститьИндекс();
ПолнотекстовыйПоиск.ОбновитьИндекс(Истина, Ложь);
Если в базе включено ограничение доступа на уровне записей (например, по организациям), это существенно усложняет SQL-запрос, который платформа отправляет к серверу. Даже если вы добавили пользователю полные права, но при этом в профиле групп доступа остались активные ограничения RLS, система все равно будет пытаться их обрабатывать.
Проверим настройки производительности RLS:
Если форма списка была изменена (кастомизирована), проанализируем сам запрос динамического списка. Использование «Произвольного запроса» с левыми соединениями (LEFT JOIN) к тяжелым таблицам (например, к регистрам сведений или остаткам) может привести к неоптимальному плану выполнения на стороне SQL.
Также не забудем об обслуживании базы данных. Если статистики SQL-сервера устарели, оптимизатор может выбрать неверный путь для выполнения запроса именно для тех параметров, которые использует данный пользователь. Рекомендуется выполнить команду обновления статистик:
-- Пример команды для MS SQL Server
UPDATE STATISTICS [ИмяТаблицыДокументаРеализации];
Если ни один из вышеперечисленных методов не помог, перейдем к «тяжелой артиллерии» — настройке Технологического журнала. Это позволит нам увидеть реальный SQL-запрос, на котором происходит «затык».
Создадим файл logcfg.xml в папке с настройками платформы со следующим содержанием:
<config xmlns="http://v8.1c.ru/7.4/get/logcfg">
<log location="C:\Logs\DBV8" history="24">
<event>
<eq property="Name" value="DBV8SQL"/>
<gt property="Duration" value="5000000"/> <!-- Ловим запросы дольше 5 секунд -->
</event>
<property name="all"/>
</log>
</config>
После этого воспроизведем проблему. В логах мы увидим текст запроса. Скопировав его и запустив в SQL Management Studio через «Display Estimated Execution Plan», мы сможем визуально определить, на каком соединении или индексе происходит потеря производительности.
В современных версиях БП 3.0 в списки часто выводятся колонки со статусами ЭДО. Попытка системы получить актуальные статусы для большого количества документов в списке может приводить к подвисанию, если есть проблемы с сертификатами или доступом к серверам оператора. Попробуйте временно скрыть колонки ЭДО в настройках формы (кнопка «Еще» — «Изменить форму»).
Также проанализируем наличие Расширений. Расширение может модифицировать запрос динамического списка «на лету», добавляя в него поля, которые не проиндексированы. Попробуйте запустить сеанс с отключенными расширениями для этого пользователя (используя параметр запуска /NoExtensions) и проверьте скорость работы формы.
Подводя итог, можно сказать, что решение проблемы зависания формы списка в 90% случаев кроется в очистке пользовательских настроек или оптимизации режима RLS. Системный подход к диагностике — от простого к сложному — позволит вам быстро вернуть пользователю комфортную рабочую среду.