Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Очень медленно ClientDataSet.Data:=DataSetProvider.Data [D7, Sybase]

Shura © (2003-10-13 11:32:00)

Привет !

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

Спасибо.

--
Shura

Shura (2003-10-14 10:35:00) [1]

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

Shura (2003-10-14 08:56:00) [2]

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

Delirium (2003-10-13 17:16:00) [3]

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

Vlad (2003-10-13 17:14:00) [4]

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

Delirium (2003-10-13 17:07:00) [5]

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

Shura (2003-10-13 16:57:00) [6]

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

Vlad (2003-10-13 16:11:00) [7]

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

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

Shura (2003-10-13 16:00: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 15:30:00) [9]

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

DenK_vrtz (2003-10-13 15:24:00) [10]

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

Vlad (2003-10-13 15:08:00) [11]

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

Nikolay M. (2003-10-13 15:04:00) [12]

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

Vlad (2003-10-13 14:36:00) [13]

ADOQuery.CursorLocation:=clUseServer

Shura (2003-10-13 14:32:00) [14]

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

--
Shura

Vlad (2003-10-13 11:34:00) [15]

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

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »