Собственно теорию помню - если флажок стоит то данные считываются порциями что то типа то что влезло в экран + 20% сверху и снизу.

Если флажок не стоит то считывается все сразу.

В итоге получается что если флажок стоит то быстрее открывается список из 100500 документов ибо данные будут отправлены на клиент не все.

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

В итоге база превращается в тыкву ибо при быстром скролле эти 20% практически мгновенно достигаются  база ломится на сервак за очередной порцией.

То есть вместо выигрыша по быстродействию имеем визуальный проигрыш.

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

Или я что то не так понимаю?

мб твой журнал тупик. покаж.

мб 1с это 1 задница

ДС свойства пользователю..... нет!

а то строки в группы и пипец

(0)
Естественно динамическое считывание имеет смысл если ведущая таблица упорядочена по индексу

Запрос находит индексное значение, добавляет положим 20 и считывает

Если индекса нет сканирует всю таблицу при скроллинге

уджас

листаем. получаем... тупит все

(5) вроде все канонически - основа это по сути список документов к которому левыми соединениями всякое цепляется

(8)
Журнал ?

(9) не, по сути форма списка...

есть документ "заказ покупателя"
в его форме списка собственно наблюдаем картину описанную в (0)
не смотря на то что основная таблица явно задана - динамическое считывание по сути негативно сказывается на отзывчиваости системы...

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

(11)
А упорядочен по дате? Или реквизиту
И есть ли соединения кроме левых

или отборы

(13) отборы етсть.
упорядочен по дате
хотя соединения тока левые
но тупит и на списках где нет отборов.

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

А просто форма списка Заказы без всяких соединений тоже тормозит ?

(17) без соединений не тормозит..

эх..

запрос смотреть надо

в свое время ушел с заполнения таблицы значений на форме в динамические списки..

походу придется обратно возвращатся..
делать таблицу значений и ее заполнять запросом и обновлять в обработке ожидания :(
как то мрачно все :(

Сначала простейший запрос без соединений - тормозит или нет

(20) быстро не скроллить не предлагать?

(21) чуть легче но подтупляют оба списка - как с динамическим считыванием так и без

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

но блин как тока появляется запрос - все.. трындец

(22) ну тут дело такое.. открывает манагер журнал (а это его основное рабочее место которое в принципе то и не закрывается никогда) и начинает в нем искать какойнить заказ скоролм....

http://xmage.ru/images/201210aya.png


не скорлить не получится

(25) научи его искать по полям и пользоваться отборами.

(26) угу..

" я примерно помню порядок цифр и то что там подряд были три заказа с примерно одинаковым откатом"

а теперь вот это фильтрами изобрази :)

а если по паре-тройке раз вверх-низ промотать,не кэшируется что ли?

А сам запрос как выглядит ?

хотя это проще сразу весь список получать за период с запасом.

(28) да судя по поведению системы - неособо
(29) х.ево :)
там жесть жестяная :) из списка документов собираются первые три колонки, ну может 4..

остальное со всей базы хреначится..

(30) угу.. походу придется вернуться в ТЗ.
установил период, получил весь список с сервера и дальше играешься

(31)
Вот есть подозрение что кроме 20 строк основной таблицы
шерстятся не 20 строк из других таблиц, а полный скан

Регистр сведений - "состояние заказа", и его отображать простым списком, если это так

(34) непрокатит.
нет такого понятия как "состояние заказа"
нужно просто много связанной информации визуально наблюдать

ща перекидаю все в ТЗ, посмотрим как оно сработает

Измерение Заказ, Ресурсы Возн Остаток, Долг и т.п.

(37) угу статусы производства, постпроизвосдтветнной обработки, доставки отгрузки и еще куча всякого типа крайний счет и краяняя отгрузка  и тд..

пробовал.. херня получается

не, только то что не вычисляется простым левым соеден и чего нет в заказе

легче один раз при проведении заполнить, чем потом на каждом пользователе каждые 10 сек вычислять

(39) да там все вычисляется простым левым соединением
тока этих соединений десяток :)

А "долг" и "Сумма зак. чист" ?

(42) долг остаток по рн
сумма чист - в запросе высчитывается но по данным заказа

пля
перекидал форму на ТЗ
все летает

один раз получили данные и далее хоть уиграйся

блин :)

зато теперь получение данных  за год весьма радует...

в общем веселуха.

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

вообщем неплохо проверить скроллинг без соединения с рн в котором долг остаток

IamAlexy, не пора-ли замутить аналитическо-поисковую форму заточенную под потребности юзеров?

(49)  по сути это она и есть

блин... с другой стороны ТЗ на форме выбирающая "все" будет на вебклиенте тупить..

пля..

чо теперь- разные формы подсовывать пользователям в зависимости от варината входа в базу?

(0) запрети этому ушлёпку пользоваться списком без отборов. Ну действительно, ну зачем ему все 100500 документов? Что он от их созерцания получит, кроме красных глаз?

+(52) хотя, это конечно не отвечает на вопрос, зачем демоническое считывание. Наверное оно для сферических пользователей в вакууме, которые понимают, что зверски скроллить большие списки плохо и не делают так

(0) а по всем этим соединениям есть индексы?

(54) + если и с индексами тормозит, сделать рс, повторяющий структуру журнала. будет летать

(55) + само собой в рс тоже индексы на все поля, по которым отбор и сортировка

Проблема скроллинга списков не имеет общего решения. В утешение могу поделиться инфой: в свое время наш спец ушел в Metro C&C там SAP. Так вот он сказал, что в большинстве АРМ'ов, особенно там где идет оперативная работа (приемщики, товароведы) вообще нет никаких списков, чтобы открыть документ нужно тупо вводить его номер, по другому документ не откроешь. Стало понятно зачем требование в накладной печатать номер заказа. Вот так очень просто и надежно решилась проблема отклика системы.
Это так для информации

Запрос покажи

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

(0)  юзай подборы/отборы/фильты, вобще большинству манагеров достаточно в журнале видеть доки за текущий день.

(60) фиг с теми журналами. справочник номенклатуры самое юзаемое.

+(57) да фирмы у которых большой докоборот делают штрихкодирование документов, потом достаточно сканернуть и все...

(0) ну а чо ты хотел. авто и есть авно. юзай обычные формы)))) как говорят тут сотни.

(57)+1 В том плане что общего решения действительно нет.
Зато на эту тему некоторые специалисты даже дисертации защищали:) Я не шучу.
1) Необходимо собрать статистику по видам запросов.
2) На основании этой статистики рассмотреть вопрос относительно издержек на доп индексы по составу полей(по которым идет сортировка).
3) Для статических небольших таблиц рассмотреть вопрос о кешировании на клиенте.
4) Для динамических небольших таблиц рассмотреть вопрос о обновлении данных(еще тот геморой)
А вообщем нужно бить по рукам и регламентами ограничивать порции получаемых данных и параметры сортировки.

Не просто же так от mssql курсоров динамических(как в 7-ке) отказываются в большинстве решений.

в 8.3 для срезапоследних вроде ввели доп таблицу итогов, должно помочь

(63) про обычные формы расскажи тем кто через веб работает
(66) рановато еще на 8.3 перехожить -  глюков  много
(57) сценарий работы не тот. У меня менеджер в этот журнал пырится весь рабочий день.

(67) дык я целиком поддерживаю: не всякая контора сможет перейти на SAP, большинству нужны всякие плюшки в виде быстроскролящихся списков за 3 года.

(68) фиг там..

2 месяца тоже актуально а при объеме заказов под тыщу за эти 2 месяца как раз и упираемся в то что надо скролить...

не оно конечно можо запретить скролл и требовать указать все мыслимые параметры в форме отбора - но это нихрена не удобно именно для конечного пользователя

(50) совсем нет, я про другое, например: есть в форме списка команда по которой вызывается вот такая поисковая фарма:
http://i061.radikal.ru/1210/b1/894c9e1b6257.jpg
по указанию критериев на всех 3 закладка формируется запрос, если резльтат поиска = 0 записей - радуем юзера,  = 1  - открываем форум этого потребителя, > 1 - открываем динамический список у которого подзапросом идёт этот самый запрос. Далее никакого листания на многие записи не предвидтся

ЗЫ форма чисто умозрительна - по итогам внедроения +20-40% к функциональности поиска будет добавлено, хотя именно в этой теме намана так рублю.

(70) пробовали.. невзлетело.

менеджеры привыкли и руководство их поддерживает: всегда проще и быстрее ввести 1-2 показателя для отбора а затем просто визуально пробежаться глазами по отобранным данным.

пример:  у меня  в журнале (25) отображаются графически статусы прозводства, постобработки, отк, отгрузки оплаты и тд..

с помощью твоей формы отбора общаясь по телефону с клиентом ответить на вопрос "как там мои заказы" - хрен ответишь :)

(71) ну так вводи с таким поиском хоть 1-2 хоть 20-30... получишь достоверный результат

Я все так  и не понял - почему не завести регистр сведений
Заполнять по подписке на событие - просто
Журнал летает

Я так делал на журнале Счетов (подписки тогда еще не было правда)

(73) ну так там многофакторный поиск... причём часто не основаный на данных какой-то записи а на нескольких записях схожих по каким-то криериям (кторых штук полста)

(73) когда то пытались - не справились
+
на тот момент времени появлялись новые контрольные точки которые в "журнал" просто вписывались в запрос и выводились колонкой.

в случае с регистром это реструктуризация, новые ресурсы, дозаполнение старых записей по новым ресурсам и тд и тп - тот еще гемор.

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

в общем куда не ткни - вилы

(76) Чем больше регистров пишется при записи документов тем больше клинов со deadlock'ами, при в геометрической прогрессии. У нас сейчас документ пишет в регистр состояние, права доступа и проводки. Сижу и думаю что бы почикать. А от том чтобы добавить еще вспомогательные регистры вообще не идет речи

(76)управляемые блокировки сводят вероятность дидлуков до минимума.

(77) не знаю, вроде включили везде управляемые блокировки, не помогло. И порядок блокировки ресурсов вроде везде одинаковый, однако ж

(78) а переписать код под блокирование только испоьзуемых объектов не забыли?

(79) а как иначе

Почему при снятии флага ДинамическоеСчитывание все равно при каждом скролле идет обращение к серверу?

(81)думаешь все данные из списка сразу передаются на клиента ?

Хорошо - скажу по другому. Не вижу абсолютно никакой разницы в поведении динамического списка и при установленном свойстве и при снятом. Почему может так быть?

глубже копай, профилером можно

Так это общее поведение ситсемы. Т.е. на всех динамических списках работает так же. Причем абсолютное большинство списков - без произвольного запроса.

я тоже разницы не увидел

А судя по (0) разница должна быть и существенная.
Вот и возник вопрос - либо я не верно понял (0) и даже при сбросе свойства динамического считывания все равно не все данные для дин. списка тянутся на клиента, либо у меня что не так настроено (хотя вроде все стандартно), либо глюки конкретной платформы (8.2.15.294)

(87) не.. у меня кстати разница есть.

берем БП, форму списка ну пусть реализаций, ее произвольном запросе цепляем левым соединением ну например остатки по 62.01 например.

разница реально будет видна при установленном флажке и без него

(88) Я прочитал прошлые твои ветки (например, про 100тыщ номенклатуры) и понял свои заблуждения. Раньше на этом не заморачивался. Т.е. я верно понимаю: на клиента в любом случае тянется только "экран" + 20% верх/низ. А флажок отвечает лишь за размер хранимой на сервере выборки?

(89) вот я сам нихрена теперь не понимаю

(90) пригласите специалиста

(91) тут полный форум специалистов-отстатысячников - хоть бы кто что то внятное сказал...

Но судя по поведению системы предположение в (89) близко к истине...

Не надо путать

1) Данные, тянущиеся с Сервера
2) Запрос, получающий часть данных

Раскиньте мозг по черепной коробке.

(94) Тогда просьба пояснить.

суть (0) в том что простейший пример, например что то типа (88) явно демонстрирует то что динамическое считывание визуально проигрывает по "отзывчивости" системы формам без этого динамического считывания и наглухо проигрывает тупорылой выгрузке в табличную часть или в ТЗ

(92) смотреть потому что надо, а не по словам пытаться понять

+(97) причем чем сложнее произвольный запрос тем соответственно больше лаги..

(98) я в (88) привел конкретный пример моделируемый на любой типовой.
+
описал свой опыт  и спросил опыт форумчан - может кто уже бодался с динсписками с этой точки зрения.

(96) При динамической - запрос тянет часть, там 40-50 записей,

При нединамическом - запрос тянет все???? и частями шлет на клиента.

(94)
1) и при флаге и без него тянется одинаковое кол-во данных
2) зависит от флага, с флагом выбирает столько сколько нужно для отображения, без - все данные.

так?

Вот интересно, присобачить ДинСписок к рег. сведений на миллион записей и нединамически - сервер падет?

(101) ну так это и есть то что я написал в (89) только другими словами.

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

хм..

Я не видел запроса.

Вдруг там есть немного магии?

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

(106) не.. там много г.вна..
но суть не в этом

на простых примерах типа левого соединения остатков по РБ к таблице списка документов выдает ровно те же результаты

Когда 1С прикрутит МенеджерВременныхТаблиц к дин. списку - тогда будет щасте.

а вот теперь вопрос номер два:

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

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

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

(108)
>>на простых примерах типа левого соединения остатков

так остатки это уже подзапрос, и судя по всему отбор в нем без временных таблиц сделать сложно
Вот и затыкается на нем

блин

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


звиздец.
особенно разница шикарно видна на вебклиенте - разово в ТЗ грузануло год оборотов (а это чо то типа 4000 заказов-строк в журнале) и далее верти крути скроль и листай как тебе нравится..

в динамическом списке происходит адская жесть.. просто киздец какая жестяная жесть :(

(113)
Как обновление списка собираешься делать ?
Типа раз в 10 сек - позиция списка в экране?