Очень медленно ClientDataSet.Data:=DataSetProvider.Data

← →
Shura (2003-10-13 11:32) [0]

Привет !

Имеется связка ADOQuery -> DataSetProvider -> ClientDataSet.
В результате выполнения SQL-запроса (время выполнения около 2-3 сек., записей ~ 22000) необходимо выполнить перенос данных ClientDataSet.Data:=DataSetProvider.Data, но это происходит ОЧЕНЬ долго, дождаться не хватило сил. Где копать ?
Не хотелось бы создавать "без посредников" ClientDataSet.CreateDataSet. Сторонние компоненты не предлагать.

Спасибо.

--
Shura

← →
Vlad (2003-10-13 11:34) [1]

>ClientDataSet.Data:=DataSetProvider.Data
Это еще зачем ?
Просто подключить DataSetProvider к ClientDataSet чем не нравится ?

← →
Shura (2003-10-13 14:32) [2]

>Просто подключить DataSetProvider к ClientDataSet чем не нравится ?
Имеется в виду ClientDataSet.ProviderName:=DataSetProvider ? Это уже сделано.
А каким образом отобразить данные скажем в Grid"е ?
Либо ClientDataSet.Data:=DataSetProvider.Data, либо ClientDataSet.Open. Результат один и тот же - медленно.

--
Shura

← →
Vlad (2003-10-13 14:36) [3]

ADOQuery.CursorLocation:=clUseServer

← →
Nikolay M. (2003-10-13 15:04) [4]

Может идеологию поправить? Зачем юзеру видеть в DBGrid-е аж 22 000 записей?

← →
Vlad (2003-10-13 15:08) [5]

>Nikolay M. © (13.10.03 15:04) [4]
Наверное как всегда, "заказчик требует..." :)))

← →
DenK_vrtz (2003-10-13 15:24) [6]

2750 записей в час при 8-ми часовом рабочем дне.
У кого такая работоспособность?

← →
Vlad (2003-10-13 15:30) [7]

45 записей в минуту.... Без обеда.... Без перекура...
Я бы помер :(

← →
Shura (2003-10-13 16:00) [8]

Итак по порядку
>ADOQuery.CursorLocation:=clUseServer
пробовал и так - запрос выполняется влет, но при открытии ClientDataSet"а по сети перетягивается весь курсор уже в сам ClientDataSet (мониторил в XP через диспетчер задач) - что еще медленнее. Поэтому оставил ADOQuery.CursorLocation:=clUseClient.

>Зачем юзеру видеть в DBGrid-е аж 22 000 записей?
А затем, чтобы он мог по своему желанию его отфильтровать и отсортировать, доведя его до разумного предела (неск. десятков максимум). Локально это происходит влет, а писать SQL-запрос не представляется возможным, так как он должен строиться уже на основании тех самых 22000 записей, которые сначала надо вытянуть на экран.

Вообще мне казалось, что перенос DataSet"а из одного компонента в другой на мощном компе (а даже и на не очень мощном) должен занимать доли секунды Celeron 1,8 Ггц, 256 Мб ОЗУ.

--
Shura

← →
Vlad (2003-10-13 16:11) [9]

>строиться уже на основании тех самых 22000 записей, которые сначала надо вытянуть на экран.

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

← →
Shura (2003-10-13 16:57) [10]

>Неужели юзер будет их все просматривать ??? Наверно нет.
Конечно нет. Есть некоторая априорная информация. Но каждый раз при появлении формы просить ввести критерий отбора неприемлемо. Надо как бы в общем виде.
Как бы там ни было, я все равно не понимаю, что может происходить внутри компонента при переносе данных, чтоб так тормозить (загрузка процессора 100%, антивирусов и прочих приблуд нет) !!!!!

← →
Delirium (2003-10-13 17:07) [11]

А для чего вообще нужен ClientDataSet? Может проще локализовать RecordSet и всё?

← →
Vlad (2003-10-13 17:14) [12]

В любом случае так делать не нужно:
>ClientDataSet.Data:=DataSetProvider.Data
ADOQuery д.б. закрыт. При этом достаточно сделать ClientDataSet.Open, и набор данных будет в нем.
Но, чтобы данные закачивались не все а по мере необходимости, нужно чтобы ClientDataSet.FetchOnDemand было true.

← →
Delirium (2003-10-13 17:16) [13]

22000 это для 100Mbit совсем не много, так что проблема у вас не в прокачке, а в преобразовании данных при переходе от ADO к ClientDataSet, вот я и спрашивую, для чего нужен этот переход?

← →
Shura (2003-10-14 08:56) [14]

to Vlad: >ClientDataSet.FetchOnDemand было true.
Это установлено по дефолту. Не фетчит он при скроллинге, сразу все преобразовывает :(
to Delirium: > 22000 это для 100Mbit совсем не много, так что >проблема у вас не в прокачке, а в преобразовании данных при >переходе от ADO к ClientDataSet, вот я и спрашивую, для чего >нужен этот переход?
Да, сетка 100 Mbit. Поэтому данные перекачиваются влет. А то, что проблема не в прокачке я видел с самого начала. Но меня терзает все тотже вопрос - что и как можно преобразовывать, чтобы получить такие тормоза. Неужели простое что-то типа Assign или присвоение DataSet"ов не логично !
А переход необходим для реализации фильтрации и сортировки в общем случае всего по всему. Объем данных такой, что составление SQL-запросов и их выполнение будет очень медленным по сравнение с мгновенным пересозданием индексов и фильтров.
ADOQuery не позволяет сорт./фильтр. по LookUp и Calc - полям.

← →
Shura (2003-10-14 10:35) [15]

ВСЕ !!!!!
Есть решение !
ClientDataSet.PacketRecords:=0.
Если больше 0 (N), тоже влет, но изначально указатель записи позиционируется на N записей вниз.
Всем большое спасибо !

Очень медленно ClientDataSet.Data:=DataSetProvider.Data Найти похожие ветки