|
УФ. Отчет СКД и относительно большое количество элементов в отборе | ☑ | ||
---|---|---|---|---|
0
palpetrovich
27.01.22
✎
10:31
|
простейший отчет с запросом:
ВЫБРАТЬ Товары.Ссылка КАК Товар ИЗ Справочник.Товары КАК Товары Отбор по товару "в списке" Если в списке 2000 товаров, то при любом клике на форме отчета - жуткие тормоза. Впрочем, тормоза заметны глазу уже на 200 элементах в отборе. Все это еще до формирования собственно отчета... Кто нить знает, что там внутри происходит в это время? |
|||
1
fisher
27.01.22
✎
10:34
|
Предположу, что неоптимизирована синхронизация контекста формы и при контекстных серверных вызовах список целиком гоняется на сервер.
|
|||
2
DrShad
27.01.22
✎
10:35
|
а каким образом формируется этот список? может сделать как-то иначе?
|
|||
3
palpetrovich
27.01.22
✎
10:36
|
(1) а есть какой-то способ в этом как то убедиться?
(2) изначально загружается из эксель, при повторном открытии - он уже там |
|||
4
fisher
27.01.22
✎
10:40
|
(3) Хороший вопрос. Самому интересно. Самое простое, что приходит в голову - врубить в параметрах запуска имитацию задержек передачи данных серверных вызовов и если характер тормозов совпадет, значит скорее всего оно и есть.
|
|||
5
palpetrovich
27.01.22
✎
10:43
|
(4) вообще как то странно все, один случайный клик на форме не сформированного еще отчет - и сидим курим )))
...может построитель в это время вычисляет сколько нужно будет вывести строк? |
|||
6
fisher
27.01.22
✎
10:46
|
(5) > вычисляет сколько нужно будет вывести строк
Зачем? ЗЫ. При высокой неопределенности нет смысла гадать. Нужно сначала собрать побольше фактов. Еще по ТЖ, вероятно, можно многое выяснить. Но я не спец по ТЖ. |
|||
7
fisher
27.01.22
✎
10:49
|
Если в ТЖ будет чисто и задержки передачи данных на тормоза не влияют, значит тормоза на клиенте. Тогда уже хрен поймешь, где именно накосячено. Нужно будет первым делом проверить поведение на последних релизах и если оно повторяемо - накатать петицию.
|
|||
8
DrShad
27.01.22
✎
10:49
|
а если просто сделать замер производительности и глянуть что он покажет?
(5) вообще странный подход к реализации отбора |
|||
9
palpetrovich
27.01.22
✎
10:49
|
(6) я тоже не спец по тх, более того, у нас не всем тж доступен )
|
|||
10
fisher
27.01.22
✎
10:50
|
Безусловно, большое количество элементов в отборе - это способ замазать архитектурные недоработки. Какого-то признака нехватает.
|
|||
11
palpetrovich
27.01.22
✎
10:53
|
да нет, при чем здесь архитектура? запрос в 0 - это чисто для проверки, реально от совсем другой
менеджер формирует файл с нужными ему позициями, скармливает его отчету - получает какой то нужный ему результат |
|||
12
fisher
27.01.22
✎
10:57
|
(11) Ну, то что менеджер "формирует файл с нужными ему позициями" в эксель - это тоже недоработка. Значит какой-то бизнес-процесс протекает в экселе, а не в 1С.
Ну, можешь переписать отчет, как вариант. Например, чтобы табличка с данными отбора загружалась во временное хранилище а при компоновке отбор применялся через соединение с ТЗ |
|||
13
fisher
27.01.22
✎
11:00
|
Или нет. Зачем через соединение. Можно же просто при компоновке впендюривать этот отбор.
|
|||
14
palpetrovich
27.01.22
✎
11:14
|
так вопрос то в том, что отчет еще не формировался, а тормоза уже есть (
сейчас сделал замер от "приОткрытии" - пишет результат до 2 сек, а реально - ну сильно дольше |
|||
15
DrShad
27.01.22
✎
11:16
|
применяй отбор не на форме, а при компоновке результата в модуле
|
|||
16
toypaul
гуру
27.01.22
✎
12:32
|
Предлагаю сделать отбор по полю "код" и посмотреть будет ли тормозить так же
|
|||
17
fisher
27.01.22
✎
12:35
|
(16) Переполучение представлений? Вариант.
|
|||
18
Kassern
27.01.22
✎
12:39
|
(0) а зачем вам этот отбор на форму выводить? Что мешает при компоновке заполнять? А лучше использовать набор данных объект и таблицей через соединение работать с этими 2000+ элементами.
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |