What about eoAsyncExecutem & eoAsyncFetch?
Wouldn't these options on an ADOQuery coupled with an OnFetchProgress event
handler updating some progress indicator be a helpful way of getting a large
number of records without the user having to wait for all of them to arrive?
I ask this because I have a similar situation where a significant number of
records must be retrieved but would like to keep the user on the loop as to
what's going on the backend and even show him the records that have been
retrieved.
I built a small project that I am using to test this options out; the problem
I'm having is that the grid is not updated and I get an Access Violation
when the fetch process starts; after that the process continues, I get some
(weird) updates on a progress bar and eventually the fetch completes.
When the fetch completes the grid displays a single record, but it allows
"paging" within that single record (i.e. the rest of the records are
displayed in the same grid row whenever one tries to navigate the grid);
even the navigator bar works in that same single grid row.
The event handler that does the updating is this one:
procedure TForm1.ADOQuery1FetchProgress(DataSet: TCustomADODataSet;
Progress, MaxProgress: Integer; var EventStatus: TEventStatus);
begin
if cancelFetch then begin
ADOConnection1.Close;
ShowMessage('Fetch cancelled')
end
else begin
ProgressBar1.Max:= MaxProgress;
ProgressBar1.Position:= Progress;
end;
Application.ProcessMessages;
ProgressBar1.Refresh
end;
I've seen a similar behavior done in the Great Plains Small Business Manager
program.
Does anyone (TeamB?) know how this should be properly done?
Best regards,
Mario Estrella
"Brian Bushay TeamB" <
XXXX@XXXXX.COM>writes
Quote
>>>Questions:
>>>
>>>1) DOES it fetch all rows?
>>Yes
>
>That strikes me as _really stupid_... Is this a driver thingy?
Its the way ADO is designed to work
--
Brian Bushay (TeamB)
XXXX@XXXXX.COM
