Какие-то дополнительные действия понадобятся вам только в том случае, если вы захотите перенести в отчёт ещё и условное оформление формы.
Динамический список — это объект построения интерфейса, который предназначен для создания списка объектов или записей. Работа динамического списка основана на системе компоновке данных. Подробнее о нем вы можете прочитать здесь, мы же сегодня в статье разберем особенности его работы с базой данных.
В статье мы рассмотрим запросы к базе данных, которые формирует платформа при работе с динамическим списком. Определим, каким-образом его настройки влияют на работу платформы с SQL-базой.
Все примеры в статье сделаны на демонстрационной конфигурации, которую Вы можете скачать по ссылке в конце страницы.
Примечание: объект формы «Динамический список» появился в платформе 8.2. Его использование возможно только для управляемых форм.
1с 8.3 удалить отбор в динамическом списке. Настройки динамического списка
Работа с базой данных
При открытии списка
В тестовой конфигурации создан справочник «Товары», в котором добавлен реквизит «Артикул» типа «Строка». Для примеров справочник заполнен пятью тысячами элементов. Заполнение произведено специальной обработкой «ЗаполнениеСправочникаТоваров», которая также находится в составе демонстрационной конфигурации.
При открытии формы списка справочника «Товары», динамический список будет содержать группы верхнего уровня, которые пользователь может разворачивать для просмотра вложенных элементов. SQL-запрос, формируемый платформой при открытии списка, будет выглядеть следующим образом:
В результате выполнения запроса мы увидим следующие данные в динамическом списке:
При раскрытии группы с элементами
Раскрывая группу элементов в динамическом списке, платформа 1С:Предприятие формирует следующий запрос:
Полученный запрос похож на рассматриваемый нами ранее. Отличие заключается лишь в количестве выбираемых записей и накладываемом условии на выборку данных. В случае, когда происходит открытие группы элементов, то платформа задает выбор только для первых 22-х элементов.
Условие осталось прежним — выбираются записи только определенного родительского элемента, только в этом случае в параметр уже передается ссылка на открываемую группу элементов. На скриншоте вы видите ссылку на группу «Группа 1 — 1».
Промокоды на Займер на скидки
- 💲Сумма: от 2 000 до 30 000 рублей
- 🕑Срок: от 7 до 30 дней
- 👍Первый заём для новых клиентов — 0%, повторный — скидка 500 руб
Примечание: подобный запрос формируется и в тех случаях, когда пользователь разворачивает группу, в состав которой входят другие группы справочника.
Пролистываем список элементов
Ранее уже было сказано, что при раскрытии группы справочника платформа формирует запрос на выборку первых 22-х элементов. Но что происходит, когда пользователь листает динамический список и выбранные элементы заканчиваются? В таком случае платформа формирует новый запрос и выбирает последующую порцию данных для просмотра:
Важным моментом в формировании данного запроса является условие выборки. В нем для тех полей, которые участвуют в сортировке результата запроса, накладываются дополнительные условия для получения последующих 22-х записей. В нашем случае это поля «_Foder», «_Description» и «_IDRRef».
Прежде чем формировать выборку последующих 22-х элементов, платформа получает данные для последнего выбранного элемента:
Передав ссылку на последний элемент, запрос получает все данные для передачи параметров в запрос для выборки следующей порции элементов (предыдущий запрос выше).
Платформа предоставляет возможность управлять периодом обновления для каждого динамического списка, присутствующего в конфигурации, в отдельности.
Анализ возможных причин
- реально большой размер списка (с этим ничего не поделать)
- некорректная работа платформы 8.3.8 (добавились кнопки листания, допускаем, что в начале производится какие-то промежуточные расчеты)
- наличие сортировки (при установке сортировка, форма запоминает настройки пользователя и восстанавливает при открытии) — отмена сортировки через свойства формы не решила проблему
- работа на файловом варианте базы данных (на первых этапах добиваемся оптимальности в этом режиме, далее оттестируем в sql)
- отборы (отсутствуют), но будут по проиндексированным полям
- наличие событий обработчиков активизации по строке (отсутствуют)
- медленная работа с диском (пока отметаем такой вариант, диск ssd)
- Пробуем вариант с использованием команды «ПЕРВЫЕ 1000», но она вызывает ошибку в том, что запрос динамического списка не должен ее содержать. Перенос «ПЕРВЫЕ» во вложенный запрос решает проблему. Дальше, наблюдается медленная работа полнотекстового поиска (поиск альтернативными средствами, достаточно не комфортно и это не позволит оперативно работать с таким большим списком на этапе его разгруппировки).
- Следующей итерацией будет внутреннее соединение двух таблиц одного справочника (второй будет формироваться с командой ПЕРВЫЕ).Цель — вернуться к основной таблице с полнотекстовым поиском.
Результаты проверки
- поиск восстановился
- отборы и поиск идет не по всему списку а по 1000 (указанной в директиве, это плохой вариант)
- поднятие выборки до 100000 дает допустимую скорость выборки и поиска (но все равно не полную)
- отключение динамического считывания — не ускоряет начальное получение данных, но ускоряет листание — происходит без задержек
- начальное формирование 2-3 секунды (при 100000) — быстрее примерно во столько же на сколько уменьшилась выборка
- при вводе длинных фраз в полнотекстовом поиске наблюдаются тормоза — необходимо запрещать поиск до 3 символов (если внести фразу сразу из буфера обмена — поиск моментальный)
3. Останавливаемся на варианте, когда полнотекстовый поиск вызывается не стандартным диалогом, а более управляемым, после этого полученный список передается как параметры отбора для динамического списка.
Реклама — двигатель торговли: сотня двигает, один торгует.
— Хенрик Ягодзиньский
Использование списков в 1С (часть вторая — отборы) | — учимся работать с 1С | Яндекс Дзен
1С подвисает при открытии большого списка
В управляемой форме даже при отсутствии произвольного запроса в динамическом списке наблюдается подвисание при начальном отображении, а также при отмене поиска.
Полнотекстовый поиск производится с приемлемой производительностью.
- Более 1 млн элементов справочника
- Полный список смотреть не надо, бессмысленно на таких объемах — возможна корректировка начального отображения с последующей работой только через уточняющие запросы
- До «разгруппировки» справочника требуется быстрая работа именно с ним, в дальнейшем — при наличии групп — предполагается что производительность должна нормализоваться
Хотя может не отработать при установки ЛиномическийОтбор Истина, в этом случае только через СКД и копирование параметров с ДинамическогоСписка.
Почему в динамическом списке отбор быстрее условий в запросе, и так ли это вообще?
Есть обработка с множеством полей отбора по 100 тысячам позиций номенклатуры.
Есть две идеи:
1. Постоянная смена запроса динамического списка (добавлять условия или удалять их, в зависимости от данных в этих полях);
2. Использовать типовой отбор.
Знакомый всеми руками за первый пункт, но его реализация дичайше тормозит. А вот типовой 1C-овский отбор списка с такими же фильтрами работает очень здраво.
Почему так происходит и в чем вообще отличие двух методов? Плохая реализация запроса?? Есть ли где-то информация об этом?
Решение упирается в текст запроса. Варианты почему условие медленное:
1) Для условия использованы подзапросы
2) В запросе используются ИЛИ
3) Условия запроса по НЕ индексируемым полям, что требует скан в плане запроса СУБД.
А если все отборы динамического списка прописаны, как «Выбор Когда. «, то, как я понимаю, получается все еще хуже?
Спасибо за совет. Получается, как и полагала, реализовать отбор типовыми отборами списка — лучший метод в подобных задачах, так?
Еще вопрос: если нужно будет ставить отбор по табличным частям в справочнике, то не лучше ли будет сделать индексируемые поля с реквизитами-строками, в которые будут собираться колонки, и отбирать уже по этим самым полям (если конфигурация самописная)?
Ответ про табличную часть зависит от количества строк. Если мало — не стоит заморачиваться. Если много — рекомендую попробовать регистр сведений подчененный документу-регистратору. Если количество неизвестного размера, то замарачиваться с индексами посоветую только при наличии проблем с быстродействием.
Дмитрий Кинаш, а как иначе можно было бы сделать отбор по строкам табличных частей номенклатуры, если отбором, насколько помню, это не предусмотрено? В моей голове всплывает тогда только идея изменять запрос списка. Что, выходит, глупо.
hloya_ram, почему же? Пишите в настройках динамического списка на закладке Отбора поле вида Ссылка.Товары.Номенклатура и накладывайте нужный отбор — получите в списке только те документы, в которых будут указанные позиции. Да, в этом случае лучше индексировать.
Дмитрий Кинаш, спасибо большое за пояснение! Я попробую. Сейчас вспомнила: было что-то такое. А есть ли где-то еще информация по данной теме (где-нибудь на its, возможно)?
hloya_ram, не знаю что именно вам интересно. Может будет полезна эти главы по отборам в динамическом списке: https://its.1c.ru/db/pubdevguide83#content:578:hdoc
Есть еще вариант, если используются вирт. таблицы регистров например: вместо установки параметров для виртуальных таблиц используются условия «ГДЕ». Которые накладываются уже после того как выбраны все данные из виртуальной таблицы
1С подвисает при открытии большого списка
Микрофинансирование → Микрокредиты → Специальные предложения → Скачать файлы → Обзор Быстроденег → Предмет договора → Ответственность сторон → Отличные наличные→ Экспресс займы
