Оптимизация динамического списка #718008

День добрый. Подскажите как в произвольном запросе дин.списка 8.3 такого вида: ************************ Выбрать ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Период, ВидЦены = &ВидЦены И Номенклатура В (&СписокНоменклатуры)) КАК ЦеныНоменклатурыСрезПоследних ПО (ЦеныНоменклатурыСрезПоследних.Номенклатура = СправочникНоменклатура.Ссылка) ************************ Указать чтобы при прокрутке списка присоединенные таблицы ограничивались теми 22 записями что читаются. Конструкция такого вида вида: РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Период, ВидЦены = &ВидЦены И Номенклатура В (&СписокНоменклатуры) {(Номенклатура).* КАК Ссылка}) КАК ЦеныНоменклатурыСрезПоследних не помогает. В профайлере видно что читаются сумасшедшие количества записей каждый раз (при параметре СписокНоменклатуры = 7000 записей читается 90000 строк из-за присоединенных таблиц) И запрос продолжает иметь Having вместо Left Join. Ну или по другому - как перехватить полученные 22 записи и уже к ним пристыковать нужные мне агрегатные колонки? Т.к. даже 22 вызова сервера по 1 записи будет быстрее, чем этот бардак.

Зачем в дин список пихать такой запрос? 1С крайне не рекомендует это делать....МДА быдло кодеры атакуют.

Предложите альтернативу?

Динамический список по номенклатуре. При активизации строки дин. списка в отдельных полях выводится интересующая информация.

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

Да и что такого в запросе то? Проблема лишь в том как указать вирт.таблице чтоб читала данные только по выбранным 22 строкам что 1С выбирает. И все будет летать.

Анализировать остатки и цены клиент может в отчетах, можно ему предложить такой отчет. Но динамический список выполняется порциями при прокрутке, следовательно ваша задача не реализуема.

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

1С уже устала разъяснять франчам, что дин список используется для вывода простой таблице, только в крайнем случае его можно перегружать соединениями и т.д., но надо понимать что серьезно страдает скорость.

И после таких внедренцев и возникает ощущение у клиента, что 1С тормозит, а именно не грамотное использование инструментов и возможностей платформы.

Отчет и форма подбора совершенно разные вещи. Хорошо. Тогда как реализовать по другому такую простейшую вещь, которая прекрасно работала на ОФ?

Угу, конечно сам виноват. Вот только есть задача и ее надо решить. А "возможности" платформы ее перестали решать.

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

Надо быть немного методологом и при постановки задачи обсуждать адекватное решение, а не делать ее в лоб. После чего будет уже трудно что то доказать  Клиенту.

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

1. ДОстаточно открыть УТ 10 и увидеть, что цены и остатки так же выводятся в нижней части формы, в отдельном окне. Если 22 колонки получаются с помощью запроса, то будет тормозить абсолютно так же, если не больше, тем более используется тормозной способ через "ПриВыводеСтроки". 2. Надо в первую очередь повернуть свой мозг в правильную сторону. Для повышения маштабируемости решений новая платформа накладывает целый ряд ограничений, которые следует выполнять, например клиент-серверное взаимодействие.

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

Получается, что 1с говорит "формируйте все данные, которые вам нужно отобразить, через запрос" и одновременно "не все запросы в динамическом списке можно применять". Тем самым, множество всех отображаемых в поле списка полей ограничивается множеством напрямую связанных данных. Это лишает разработчика выдать пользователю результат с косвенно связанными данными непосредственно в форме списка, приходится реализовывать отчет - а это влияет на эргономику работы пользователя.. То есть, налицо идеологическая диверсия фирмы 1с против России.

Чем отчет пагубно влияет на эргономику работы? Можно хоть ТЗ реализовать. Важно все получить одним запросом.

Зачем в запросе группировка? А параметр "Период"? Если нужны текущие данные, то он лишний, иначе предлагаемый в отчёт вполне подойдёт. А 90000 строк из каких таблиц берутся? Там, вроде, ограничение по списку есть.

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

1. Зачем открывать штатный функционал, если есть написанная удобная форма, где все что надо выводится в списке. Потому что это просто УДОБНЕЕ. Не надо теоретизировать. Для видимых строк пусть даже с получением 22 раза по 1 записи от сервера ЭТО В РАЗЫ БЫСТРЕЕ чем динамический список лопатящий 90000 записей при каждой прокрутке. Кстати попутно вопрос. Почему даже если отключаю галку "Динамическое считывание данных"- ничего не меняется. Уж пусть бы грузил подольше, зато потом прокрутка не занимала времени? 2. 95% пользователей 1С это мелкие предприятия с 5-10 пользователей. Им это масштабирование как бы это помягче сказать. А пока что они видят лишь то, что УТ11 тупо тормознее чем УТ10.3. Равно как и Бух3 vs Бух2 Вообще о чем спор? Есть задача которую надо решить - не знаете - хорошо. Может кто другой предложит вариант решения.

1) Надо посчитать остатки по всем складам. Настоящий запрос чуть сложнее есть еще цены поставщиков, из которых и выбирается минимальная. 2) &Период так понимаю значения не имеет - привычка. Разницы все равно нет. 3) 90000 это совокупность связанных таблиц. Т.е. 7000 товаров и 3 присоединенных регистрасведений. Выводится разумеется 7000 строк.

Костыли еще те. Нагрузка на базу, т.к. пересчитывать надо постоянно. Иначе будет вопрос к актуальности данных.

Убери фильтры на вирт таблицы и параметр период, или тебе нужны остатки на вчера ? Тогда все будет считаться по готовой таблице итогов, наверное ;)

Если сделать головой, а не руками, то вполне нормально. В случае сложного запроса в списке нагрузка гораздо выше, да помножь на количество пользователей. Важность актуальности данных часто преувеличена. В учете очень немного есть моментов, где действительно нужно видеть остатки в реальном времени.

а вообще у меня до фига вопросов по дин спискам. И дикие тормоза при выводе и  тупая настройка фильтров и невозможность управлять и отображать поля, по которым произведен поиск. Начиная работать с уф, ожидал развития механизмов в итоге все так и осталось в зачаточном состоянии

дин.список — весьма крутой Grid. Близких аналогов ему я даже подобрать не могу.

обычный, чего в нем крутого?после 77 он не плох,, конечно

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

Добавь регистр актуальных цен с нужными полями? обновляй при записи набора записей в регистр цен и будет тебе счастье.

Да убрал уже все что можно. Даже группировку убрал ради теста. Фактически осталось только срезпоследних и отстаки. А все равно подтормаживает при прокрутке. Хотя чем плох фильтр по номенклатуре у регистров (по идее должен ограничивать количество читаемых записей)?

а если во вложенном запросе данные по регистру сведений отобрать и потом присоединить?

Выбрать Первые 22 уже предлагали?:-)

если убрать все параметры вт, по идее должен строить запрос по таблице итогов. У тебя с ней и так будет джоин. А тормозить не перестанет, не надейся.

Вложенный запрос это вообще смертный приговор дин.списку. Откуда их выбирать?