В практике разработчика и администратора 1С нередко встречается загадочная ситуация: конкретная форма списка (например, справочника Номенклатура или списка документов РеализацияТоваровУслуг) открывается мгновенно у всех сотрудников, кроме одного. У «проблемного» пользователя система уходит в длительное ожидание, хотя аппаратная часть и сетевое соединение в порядке. Еще более странным кажется то, что создание полной копии этой же формы в конфигураторе решает проблему — копия «летает» даже у этого пользователя. Разберем детально, почему так происходит и как эффективно устранить эту проблему, не прибегая к созданию дублей объектов.
Проанализируем ситуацию. Если запрос динамического списка, запущенный в консоли запросов под тем же пользователем, работает быстро, значит, проблема не в правах доступа (RLS) и не в самой структуре базы данных. Основная причина кроется в Хранилище системных настроек. Платформа 1С сохраняет индивидуальные настройки каждого пользователя для каждой формы: отборы, сортировки, группировки, состав колонок и, что самое важное, Условное оформление.
Рассмотрим механизмы, которые приводят к деградации производительности:
Ссылка.Склад.ОтветственноеЛицо), платформа вынуждена добавлять неявные LEFT JOIN в SQL-запрос для каждой строки. В консоли запросов вы проверяете «чистый» код, а в форме работает «утяжеленный» настройками монстр.Ответ на вопрос, почему копия формы работает быстро, прост: каждая форма имеет свой уникальный идентификатор. Для системы копия — это совершенно новый объект, для которого в базе еще нет накопленного «груза» старых и кривых настроек в системном хранилище.
Если мы определили, что проблема локализована в настройках конкретного пользователя, самым быстрым и радикальным способом будет использование метода ОчиститьНастройкиПользователя(). Этот метод полностью удаляет записи из системных хранилищ для указанного лица.
Рассмотрим пример кода, который можно запустить во внешней обработке или в консоли кода под правами администратора:
// Очистка настроек для текущего пользователя, под которым запущен сеанс
ПользовательОбъект = ПользователиИнформационнойБазы.ТекущийПользователь();
ОчиститьНастройкиПользователя(ПользовательОбъект);
Сообщить("Настройки успешно очищены для пользователя: " + ПользовательОбъект.Имя);
Если нам нужно очистить настройки конкретного сотрудника, не заходя под его учетной записью, мы можем найти его по имени:
// Очистка настроек по имени пользователя
ИмяНужногоПользователя = "ИвановИИ";
ОчиститьНастройкиПользователя(ИмяНужногоПользователя);
Важный нюанс: данный метод в «толстом клиенте» удаляет вообще все настройки (панели, избранное, настройки отчетов). Чтобы действовать более избирательно, лучше воспользоваться встроенными инструментами современных конфигураций.
В большинстве современных конфигураций на базе БСП (Библиотеки Стандартных Подсистем), таких как ERP, УТ 11, БП 3.0 или ЗУП 3, существует возможность точечного управления настройками. Это позволяет нам не «сбрасывать» пользователя полностью, а удалить настройки только для одной проблемной формы.
Разберем шаги по очистке:
Этот метод является предпочтительным, так как он сохраняет все остальные удобства работы пользователя в системе, исправляя только конкретный сбой.
Бывают ситуации, когда очистка настроек помогает лишь на время, и через неделю форма снова начинает тормозить. В этом случае нам нужно выяснить, какой именно элемент настроек «ломает» производительность. Проанализируем ситуацию с помощью Технологического журнала.
Настроим сбор событий DBMSSQL (или DBPOSTGRS) и обратим внимание на параметр PlanSQLText. Нам нужно найти запрос, который выполняется аномально долго. Сравнив текст этого запроса с исходным текстом из конфигуратора, мы увидим:
SELECT).JOIN).WHERE).Часто выясняется, что пользователь установил отбор по подстроке (использование ПОДОБНО %текст%) в поле, содержащем неограниченную длину или огромный объем данных. В таком случае решением будет не просто очистка настроек, а административный запрет на использование подобных фильтров или индексация соответствующих полей (если это возможно).
Посмотрим на другие аспекты, которые могут влиять на поведение формы:
Кэш метаданных на сервере: Иногда проблема кроется в сеансовых данных. Если очистка пользовательских настроек не помогла, попробуйте завершить все сеансы пользователя и, если это возможно, перезапустить службу кластера серверов 1С. В некоторых случаях помогает удаление временных файлов в профиле пользователя на сервере (папки AppData\Local\1C\1Cv8 и AppData\Roaming\1C\1Cv8).
Динамические обновления: Как упоминалось в сообщениях форума, старайтесь избегать «динамических обновлений» (обновление конфигурации БД при работающих пользователях). Это часто приводит к «рассинхрону» кэша и странному поведению форм. После любого динамического обновления рекомендуется перезапускать клиентские сеансы.
Права доступа (RLS): Хотя в исходной проблеме RLS был исключен (так как копия формы работала), всегда стоит помнить, что механизмы ограничения доступа на уровне записей добавляют сложные подзапросы в динамические списки. Проверьте, не изменился ли состав групп доступа у пользователя непосредственно перед появлением проблем.
Подведем итог: в 90% случаев «зависание» формы у одного человека лечится очисткой настроек этой формы. Всегда начинайте диагностику с этого простого шага, прежде чем приступать к переписыванию запросов или изменению структуры метаданных.