Асинхронное выполнение

← →
DPetrovich (2002-12-25 15:57) [0]

Ситуация такая - есть связка ADOConnection->ADOQuery->DataSource->DBGrid
Ставлю в ADOQuery.ExecuteOptions=[eoAsyncExecute], но после ADOQuery.Open получаю ошибку "Access violation at address..."
Интеречно, что если не передавать данные в DBGrid, то ошибки не возникает. В чем проблема? И ещё вопросик - как определить что асинхронное выполнение запроса завершено? Заранне благодарю.

← →
zx (2002-12-25 16:28) [1]

> ADOQuery.ExecuteOptions=[eoAsyncExecute]
а это за чем?
а если без этого?

← →
sniknik (2002-12-25 16:30) [2]

Делай так
ADODataSet1.DisableControls; ADODataSet1.Open; while ADODataSet1.State = dsOpening do begin ProgressBar1.StepIt; Application.ProcessMessages; sleep(100); end; ProgressBar1.Position:= 0; ADODataSet1.EnableControls;
примерно естественно, можеш внести изменения.

← →
sniknik (2002-12-25 16:31) [3]

zx © (25.12.02 16:28)
полезно чтобы не тормозило.

← →
DPetrovich (2002-12-25 16:31) [4]

ну это типа специальная фича для выполнения запроса асинхронно ... а как подругом? через TThread?

← →
passm (2002-12-25 16:39) [5]

DPetrovich © (25.12.02 16:31)> Создать поток со свойством DataSet: TDataSet
procedure TThread.Execute;
begin
Synchronize(FDataSet.DisableControls);
try
FDataSet.Open
except
on E: Exception do
...
end;
Synchronize(FDataSet.EnableControls)
end;

← →
DPetrovich (2002-12-25 16:48) [6]

sniknik, спасибо!!!
А как бы ещё сделать чтобы данные не целиком выплёскивались, а порционно?
passm, а это поможет порционно вытягивать ?

← →
passm (2002-12-25 16:56) [7]

DPetrovich © (25.12.02 16:48)> ИМХО не поможет.

← →
sniknik (2002-12-25 17:19) [8]

CacheSize:= 30; //примерно сколько в гриде строк //одномоментный показ
и
ADOQuery.ExecuteOptions=[eoAsyncFetch];

← →
sniknik (2002-12-25 17:20) [9]

ADOQuery.CacheSize:= 30;

← →
DPetrovich (2002-12-25 17:26) [10]

не помогает :(
всё остальное также оставить?

← →
DPetrovich (2002-12-25 17:48) [11]

зато
eoAsyncFetchNonBlocking помогло

← →
sniknik (2002-12-25 18:01) [12]

остальное также с циклом. у меня работает.

помогло, работает? значит больше не трогай! ничего не меняй. :-)

← →
DPetrovich (2002-12-25 18:32) [13]

у меня подозрение, вернее даже уверенность, что если eoAsyncFetchNonBlocking, то он не все записи грузит...
Ещё раз скажи, плиз, как ты делаешь, ADOQuery.ExecuteOptions=[eoAsyncFetch] или [eoAsyncExecute,eoAsyncFetch] ?

← →
sniknik (2002-12-25 18:44) [14]

делаю так
ADOQuery.ExecuteOptions=[eoAsyncFetch]

но и оба [eoAsyncExecute,eoAsyncFetch] тоже работают разница небольшая получается.
(вообщето с ADODataSet просто отвечал сбился почемуто, квери и тайбл использую только в тестах)

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

← →
passm (2002-12-26 11:11) [15]

Вытягивание данных с сервера порционно ИМХО проблематично (невозможно) исходя из принципов клиент/сервер.

← →
sniknik (2002-12-26 11:36) [16]

passm © (26.12.02 11:11)
и тем не менее.

может неправильное понимание принципов?. :-))

с eoAsyncFetch запрос выполняется 1 раз (не нарушая принципов клиент/сервер) но асинхронно в паралельном потоке не тормозя основной, а вот полученные данные отдаются по мере поступления. где нарушение?
никто же не делает запросов
SELECT TOP 30 ....
SELECT NEXT TOP 30 ....
и т.д.

← →
DPetrovich (2002-12-26 11:36) [17]

У меня с eoAsyncFetch не получается порционно, а с eoAsyncFetchNonBlocking получается, но как-то странно,
ADOQuey.State становится сразу dsBrowse и поэтому ProgressBar не отрабатывает...
но записи действительно постепенно грузятся,
просто я сначала посмотрел ADOQuery.recordcount и удивился, что их мало, но потом выяснил что это значение со временем меняется!
И всё же интересно как у тебя без eoAsyncFetchNonBlocking получилось, может ты ещё какие-нибудь параметры ставил?

← →
DPetrovich (2002-12-26 11:47) [18]

кстати, при eoAsyncFetch почему то тоже ADOQuey.State становится сразу dsBrowse, поэтому и зависает после EnableControls

← →
passm (2002-12-26 11:49) [19]

← →
sniknik (2002-12-26 12:03) [20]

DPetrovich © (26.12.02 11:36)
> может ты ещё какие-нибудь параметры ставил
да вроде нет особо не менял, может CursorLocation влияет (логически подумать то возможно) у меня у DataSet он clUseClient, у ADOConnection clUseServer.

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

passm © (26.12.02 11:49)
понять несложно, ты каждый день такое делаеш, просматриваеш интернет страници не дожидаясь конца загрузки? уже смотриш а она там еще пыжится банеры подгружает (и все с одного запроса). полный аналог.

← →
DPetrovich (2002-12-26 17:59) [21]

sniknik, изменение CursorLocation не помогает.
Проблема ещё в том, что при eoAsyncFetchNonBlocking прога хоть и не подвисает сразу, но потом когда данные поступают все (а их > 1.000.000) начинает тормозить. Хотелось бы чтобы данные не все грузились сразу, а по мере движения в DBGrid"е ... или это не реально?

← →
sniknik (2002-12-26 19:01) [22]

Памяти не хватает наверное. А если просто открыть? без асинхронных наворотов, запрос - подождал пока загрузится и тогда по гриду лазить? также тормозит?
1.000.000 в грид это не совсем правильно, для того и SQL чтобы только актуальные данные смотреть/работать. а столько никто не с состоянии осмыслить.
Почему нереально реально (только трудновато), как я я себе мыслю, в таблицу поле добавить автоикремент и загружать порциями типа SELECT * FROM .... WHERE ID BETWEEN 1 AND 100
и т.д. при подходе к концу/началу порции догружать
SELECT * FROM .... WHERE ID BETWEEN 80 AND 180
(в другой датасет) и подменять их в ответственный период. Но чтобы юзер этого не заметил надо так датасетами жонглировать.... и естественно избыточность (данных больше) сеть перегружаеш одна надежда что юзер не 3 странице все бросит. Вот так примерно. А вот если каким параметром такое сделать попроще то такого не бывает по моему.
Лутще запрос с условиями пожостче и давать только нужные данные.

Асинхронное выполнение Найти похожие ветки