8.2 - журнал документов, динамический список - большие объемы данных #555068

Документов пока не так уж и много подгружено 400 000, сейчас добавлю еще 1 500 000 другого типа а форма списка уже тормозит на форме надо картинкой строк показывать тип документа запрос: ВЫБРАТЬ    ЖурналДокументовПервичныеДокументыПациента.Ссылка,    ЖурналДокументовПервичныеДокументыПациента.Дата,    ЖурналДокументовПервичныеДокументыПациента.ПометкаУдаления,    ЖурналДокументовПервичныеДокументыПациента.Номер,    ЖурналДокументовПервичныеДокументыПациента.Тип,    ВЫБОР КОГДА ЖурналДокументовПервичныеДокументыПациента.Тип = Тип(Документ.РегистрацияПациентаВПоликлинике) Тогда 1    КОГДА ЖурналДокументовПервичныеДокументыПациента.Тип = Тип(Документ.РегистрацияПациентаВСтационаре) Тогда 2    ИНАЧЕ 0 КОНЕЦ КАК КартинкаТипаДокумента,    ЖурналДокументовПервичныеДокументыПациента.Пациент КАК Пациент ИЗ    ЖурналДокументов.ПервичныеДокументыПациента КАК ЖурналДокументовПервичныеДокументыПациента список обновляется порядка двух минут sql естественно ... и что делать? при этом если на список наложить отбор по пациенту, то все ОК, летает

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

какой тип отображения списка?

платформа: 8.2.14.439

попробуй поставить отображение не "Дерево", а "Список". Хотя платформа 14 - вообще жутко глючная, до релиза ее бы не советовал...

на сворачивании группы подвисла конкретно - нажал на сворачивание 7/30 - сейчас 7/40 - все еще

+ я в динамических списках с ней кучу глюков словил

динамическое считывание +  основная таблица должны помочь

а "Не дерево" сможет отображать дерево? - у меня группировка по датам - все стоит

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

щас отвиснет попробую

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

приехали - sql положило

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

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

должна но необязана.. что мешает "подстраховаться" ?

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

попробуй сначала

поменял "Дерево" на "Список" убрал из запроса "ВЫБОР" по типу - нет изменений

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

+ хотя есть - теперь сворачивание группировок летает

да это понятно, что есть возможности обхода меня интересует сейчас суть проблемы - и можно ли её обойти оставив "типовой" подход

+ наверняка пользователи сказали "хотим видить все документы".. а нафига им это - не объяснили... у меня как то клиенты тоже ныли.. хотим отчет где видно все! я помнится из принципа сделал клиентам отчет на СКД который порядка 2 млн. строк выводил - как просили :) сделал туда листание.. как в браузере снизу (номер страницы) на каждой странице по 100-500 строк... как думаешь, этим отчетом хоть кто то пользуется? :)

еще можешь попробывать загрузить базу в 13-ю платформу

дождаться стабильной платформы (ну или на 460ую обновить) и далее эксперементировать на тему какие элементы формы быстрее отображают данные :)

похоже подвисает именно сам запрос по журналу документов - т.е. виснет на обновлении списка

раз уж проверяешь, а если произвольный запрос отключить?

- аналогично

460 не помогла

теперь вот просто справочник пациентов 200 000 записей - форма выбора намертво вешает прогармму

вешает сервер 1С на 98% процессорного времени rphost.exe который

496 помогла, справочник стал открываться и достаточно шустро журнал документов - подвисает секунд на 30, но открывается