Как устранить зависания запросов и восстановить доступ к реквизитам после обновления 1С до платформы 8.3.13

← На главную

Переход на новые релизы платформы 1С:Предприятие, особенно такие значимые, как ветка 8.3.13, часто сопровождается неожиданными техническими сложностями. Разработчики сталкиваются с тем, что проверенный годами код начинает вести себя нестабильно: отчеты «вешают» систему, а пользователи с ограниченными правами теряют доступ к полям, которые раньше были открыты. В этой статье мы подробно разберем причины возникновения таких проблем и найдем способы их решения.

Оптимизация запросов: коварство оператора В ИЕРАРХИИ

Одной из самых острых проблем при переходе на 8.3.13 становится резкое замедление или полное «зависание» выполнения запросов. Проанализируем типичную ситуацию: код, который раньше отрабатывал мгновенно, теперь вызывает бесконечное ожидание на строке Запрос.Выполнить(). Выясним причину этого поведения.

В платформе 8.3.13 был существенно переработан оптимизатор запросов. Если в тексте запроса используется оператор В ИЕРАРХИИ, а в качестве параметра передается массив или список значений, содержащий только элементы (без групп) или пустые значения, платформа может генерировать крайне неэффективный SQL-код. Рассмотрим пример проблемного участка:


// Пример кода, вызывающего зависание на платформе 8.3.13
Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |   Взаиморасчеты.СуммаОстаток
    |ИЗ
    |   РегистрНакопления.Взаиморасчеты.Остатки(&Период, Контрагент В ИЕРАРХИИ (&СписокКонтрагентов)) КАК Взаиморасчеты";

// Если в СписокКонтрагентов передаются только конечные элементы (не группы), 
// на новых платформах это может привести к деградации производительности.
Запрос.УстановитьПараметр("СписокКонтрагентов", МассивСсылок);
Результат = Запрос.Выполнить(); // Здесь происходит зависание

Решение проблемы: если вы точно знаете, что в параметрах передаются только элементы справочника, а иерархический поиск не требуется, необходимо заменить оператор В ИЕРАРХИИ на обычный оператор В. Это позволит оптимизатору SQL построить простой и быстрый план выполнения запроса.


// Исправленный вариант для ускорения работы
Запрос.Текст = 
    "ВЫБРАТЬ
    |   Взаиморасчеты.СуммаОстаток
    |ИЗ
    |   РегистрНакопления.Взаиморасчеты.Остатки(&Период, Контрагент В (&СписокКонтрагентов)) КАК Взаиморасчеты";

Рассмотрим еще один важный аспект: проверку типов. В новых версиях платформы критически важно проверять, чтобы в массив параметров не попадали значения NULL или элементы разных типов, не поддерживающих иерархию. Это может привести к бесконечному циклу вычислений на уровне менеджера базы данных.

Проблема недоступности полей формы: RLS и функциональные опции

Часто после обновления программно созданные или самописные отчеты начинают вести себя странно: поля Организация или числовые реквизиты становятся недоступными для редактирования, хотя в конфигураторе свойства ТолькоПросмотр установлено в Ложь, а Доступность — в Истина. При этом у пользователей с полными правами все работает корректно.

Проанализируем ситуацию: почему внешние отчеты работают исправно, а встроенные в конфигурацию — блокируют поля? Причина кроется в ужесточении контроля прав доступа на уровне отдельных полей (Field-level Security) и механизме RLS.

Проверка прав на реквизиты: В версии 8.3.13 платформа стала более строго проверять права не только на весь объект, но и на каждый его реквизит. Если у роли пользователя нет права «Редактирование» на конкретный реквизит в дереве метаданных конфигурации, платформа принудительно блокирует это поле на форме, игнорируя программные установки.
Влияние функциональных опций: В типовых конфигурациях, таких как Бухгалтерия предприятия 3.0, поле Организация часто связано с функциональной опцией ИспользоватьНесколькоОрганизаций. При обновлении кэш функциональных опций может работать некорректно.
Безопасный режим: Внешние отчеты часто запускаются с другими настройками профилей безопасности, что объясняет их «работоспособность» по сравнению со встроенными объектами.

Выясним, как это исправить. Посмотрим на свойства роли пользователя. Необходимо убедиться, что для данного отчета или обработки в составе конфигурации у пользователя проставлены права на Просмотр и Редактирование для каждого конкретного реквизита, а не только для всего объекта в целом.

Метаданные и GUID: почему помогает копирование объекта?

Интересный феномен: если создать копию отчета в конфигураторе, он начинает работать правильно. Разберем, почему так происходит. При копировании объекта 1С присваивает ему новый внутренний идентификатор (GUID). Для системы прав доступа и механизмов кэширования это абсолютно новый объект, для которого еще не накоплены «битые» настройки или специфические ограничения RLS, привязанные к старому идентификатору.

Однако загрузка внешнего отчета обратно «с заменой» старого объекта возвращает проблему, так как GUID сохраняется. Чтобы решить проблему без пересоздания объектов, рекомендуем выполнить следующие действия:

Выполнить полное Тестирование и исправление (ТиИ) базы данных с очисткой ссылок и проверкой логической целостности.
Очистить серверный и клиентский кэш. Для клиентского кэша эффективнее всего удалить базу из списка и добавить её заново, чтобы сменился идентификатор папки в %AppData%\Local\1C\1cv8.
Проверить настройки автоматического запрета редактирования. Платформа 8.3.13 может блокировать поля, если считает, что объект не прошел проверку по функциональным опциям.

Особенности работы в файловом режиме

Если ваша база работает в файловом режиме, переход на 8.3.13 может вызвать общую деградацию производительности. Это связано с изменением алгоритмов блокировок в файле 1Cv8.1cd. Рассмотрим шаги по оптимизации:

Во-первых, проверьте полнотекстовый поиск. Часто после обновления индекс становится невалидным, что вызывает зависания даже при открытии простых журналов документов. Используйте стандартную обработку УправлениеПолнотекстовымПоиском для очистки и полного пересоздания индекса.

Во-вторых, обратите внимание на объем оперативной памяти. Релиз 8.3.13.1513 известен определенными утечками памяти при работе с тяжелыми отчетами. Если зависания продолжаются, стоит рассмотреть переход на более стабильные сборки, например, ветку 8.3.12.1616 (если конфигурация позволяет понизить версию платформы) или более поздние патчи в рамках 8.3.13/14.

Итоги и рекомендации

Подведем итог нашему анализу. Если вы столкнулись с «чудесами» после обновления на 8.3.13:

Проверьте все тяжелые запросы на наличие В ИЕРАРХИИ. Если иерархия не нужна — смело меняйте на В.
Проверьте права доступа на уровне Реквизитов в метаданных для проблемных ролей.
Обязательно проведите регламентные работы: очистку кэша, перестроение индексов и ТиИ.
Убедитесь, что функциональные опции, влияющие на видимость полей (например, по учету нескольких организаций), включены и актуальны.

Следуя этим шагам, мы сможем восстановить стабильную работу системы и обеспечить пользователям необходимый уровень доступа к данным.