I have a simple query (liveresult=true), like this:

select * from tmp where fieldA=0

Then I loop through the result set and updates the value of fieldA. Problem
is I end up only updating every second record. Is the query re-run for every
post operation or whatever is going on? It seems as if a filter is being
used under the hood. I have just updated my code from TTable to TQuery to
prevent this and I'm quite surprised.

Using 3.30.

Regards
Uffe

"Uffe Kousgaard" <oh@no.no> wrote in message
news:9125FC03-CF08-4D2B-9AE9-95A14394592B@news.elevatesoft.com...
>I have a simple query (liveresult=true), like this:
>
> select * from tmp where fieldA=0
>
> Then I loop through the result set and updates the value of fieldA.
> Problem is I end up only updating every second record. Is the query re-run
> for every post operation or whatever is going on? It seems as if a filter
> is being used under the hood. I have just updated my code from TTable to
> TQuery to prevent this and I'm quite surprised.
>

You've run into a pretty common programming error. You are on record 1 of a
set of 1-3 that satisfy the filter. You update record 1 so that it does not
satisfy the filter anymore. Now your current record is 2. You do a next, and
your current record becomes 3. You have completely missed record 2.

A live query is basically a tTable, and will behave the same way, the where
clause is just a a filter. With a canned query, of course, the filter gets
applied as part of creating the result dataset, so there would be no
problem.

You need to code it as

if need to update then begin
 edit
 change fieldA
 post
end else next;

Robert

Uffe

Robert is absolutelly right.
Another way is looping throught a SQL result and instead of call Next, call
First

while not Table.Eof do begin
   // Do the changes
   Table.First;
end;

Eduardo

"Robert" <ngsemail2005withoutthis@yahoo.com.ar> wrote in message
news:8562FD41-3F37-4945-8238-FB295CB2E4C5@news.elevatesoft.com...
>
> You've run into a pretty common programming error.

I had actually thought using a query would skip this problem compared to
using a table's filter.


> A live query is basically a tTable, and will behave the same way, the
> where clause is just a a filter.

Does the BDE behave the same way? I see a filter as something different from
a query and implementing a query's where clause as a filter is an error,
IMO.

According to the documentation, a liveresult is "editable and all changes
are reflected in the source table". Nothing about the query is also re-run
(effectively anyway), when changes are made.

A liveresult is a list of record ID's and there is no reason for that list
to change, just because the values in the records change.

Regards
Uffe

Uffe Kousgaard wrote:
....
> A liveresult is a list of record ID's and there is no reason for that
> list to change, just because the values in the records change.

Not true, at least not for DBISAM. It's a bitmap, like the one generated by
a table filter. You work on the real thing.

Ralf

"Jose Eduardo Helminsky" <contato@hpro.com.br> wrote in message
news:57E2ECB8-7818-49F9-BC90-D8460DBE6A87@news.elevatesoft.com...
> Another way is looping throught a SQL result and instead of call Next,
> call First
>
> while not Table.Eof do begin
>    // Do the changes
>    Table.First;
> end;

Assuming you change every record so that is is filtered.

Robert

Robert

You are *again* absolutelly right.

Eduardo

Uffe,

<< Does the BDE behave the same way? >>

It's been a while since I've run a live result in the BDE, but as far as I
remember, yes.

<< I see a filter as something different from a query and implementing a
query's where clause as a filter is an error, IMO. >>

No, it isn't. A live result is the same as a dynamic result set cursor in
ODBC or a SENSITIVE cursor in ANSI-standard SQL, which means that any
changes to the result set, either by the current user or any other user, is
reflected in real-time in the result set cursor while navigating, etc.

<< According to the documentation, a liveresult is "editable and all changes
are reflected in the source table". Nothing about the query is also re-run
(effectively anyway), when changes are made. >>

The query is not being "re-run", you're simply modifying the records so that
they no longer satisfy the query's WHERE condition.

<< A liveresult is a list of record ID's and there is no reason for that
list to change, just because the values in the records change. >>

No, what you describe is a "keyset", which is a part-live, part-canned
monster.  In ANSI-standard SQL, a result set cursor is either sensitive to
the changes from other users or it is not sensitive to the changes from
other users.  There's no in-between.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:23930E24-FE9A-4EF5-8A3D-9A2C7417422B@news.elevatesoft.com...
> Uffe,
>
> << Does the BDE behave the same way? >>
>
> It's been a while since I've run a live result in the BDE, but as far as I
> remember, yes.

It does, I just tested it. I'll just have to accept it behaves differently
from what I expected and find logical.

Thanks for the explanation.

Regards
Uffe