I have a hair puller and I know I must be missing something obvious.

DBIsam 4.27

I am obtaining a live result set and iterating through the query as so
updating a TDBIsamtable as well like so...

Query.First
while not Query.EOF do
begin
 LocalTable.FieldByName('RF_DATE').AsDateTime :=
Query.FieldByName('RF_DATE').AsDateTime;
 T.Clear;  {this is a tstringlist}
 T.Assign(TMemoField(Q.FieldbyName('RF_READBY')));
  index := T.IndexOf(ThisComputerName);
  if index = -1 then
  begin
      T.Add(ThisComputerName);
      Q.Edit;
      TMemoField(Q.FieldByName('RF_READBY')).Assign(T);
      Q.Post;
  end;
  LocalTable.Post;

 Query.Next
end;

The problem is that the Query.EOF is reached with only about
half of the records in the result set being processed.  It seems the
Query.edit then Query.post advances to the next record in the
result set and then Query.next advances again to the next record
so that only half the records get processed.

I have tried using Query.First, Query.MoveBy(Counter) at the top
of the look instead of While not Query.EOF but I still get the same
behavior with only have the records being processed.

What I tried was...

for i := 0 to Pred(Query.RecordCount) do
begin
   Query.First;
   Query.MoveBy(i);
....{same other logic as above}


end;

Can someone help me figure out what is going on here ?

Thanks
JT

John,

<< The problem is that the Query.EOF is reached with only about half of the
records in the result set being processed.  It seems the Query.edit then
Query.post advances to the next record in the result set and then Query.next
advances again to the next record so that only half the records get
processed. >>

Yes, live queries are subject to fly-aways because you are editing the
actual records in the table.  However, you are only editing a memo field,
which cannot be indexed directly, so I'm at a loss to explain why any of the
records are subject to fly-away conditions.   Are you editing any other
fields that you're not showing ?

--
Tim Young
Elevate Software
www.elevatesoft.com

John
>
> The problem is that the Query.EOF is reached with only about
> half of the records in the result set being processed.  It seems the
> Query.edit then Query.post advances to the next record in the
> result set and then Query.next advances again to the next record
> so that only half the records get processed.

If your query's WHERE clause includes RF_READBY assigning a value to it may
"eliminate" that record from the live query (if it no longer satisfies the
condition in the WHERE clause), the cursor then moves to the next record and
calling next skips it.

John

John ,

The where clause does indeed involve the rf_readby field so
that would explain it.

Now to figure out how to accomplish this...

JOhn

"John Hay" <j.haywithoutdot@crbsolutionsremoveallthis.co.uk> wrote in
message news:C94DBE3D-D6A0-4516-9257-3D40F8A511AB@news.elevatesoft.com...
> John
>>
>> The problem is that the Query.EOF is reached with only about
>> half of the records in the result set being processed.  It seems the
>> Query.edit then Query.post advances to the next record in the
>> result set and then Query.next advances again to the next record
>> so that only half the records get processed.
>
> If your query's WHERE clause includes RF_READBY assigning a value to it
> may
> "eliminate" that record from the live query (if it no longer satisfies the
> condition in the WHERE clause), the cursor then moves to the next record
> and
> calling next skips it.
>
> John
>
>