Tim

I must be mistaken.  I thought earlier in the thread you told me that the best way of getting consistent data back from EDB using a query was to
use a RANGE clause.

Now you're telling me that if I use the range clause, I either cannot rely on the consistency of the data (I'm looking at the data as it was at the
time when I asked for it), or that I have to lock all other users out of the records until I'm finished with them (with locking).

How's that ever going to fly?

Karl,

I don't remember Tim has ever said something about data consistency
related with "range", but he can speak by himself, so I will not enter
into this discussion.

I'm just curious about what you said:
What do you mean with "getting consistent data"? Consistent with what?
As I undestand it, data will be "consistent" in the sense that you will
see exactly what's in the database at the very moment you asked for it.

If you want the table to stay as it WAS when you started the query you
can always start a restricted transaction on the tables referenced by
your query... of course this will prevent others from changing data in
this tables, but that's what you want, isn't it?

--
Fernando Dias
[Team Elevate]

Karl,

<< I must be mistaken.  I thought earlier in the thread you told me that the
best way of getting consistent data back from EDB using a query was to use a
RANGE clause. >>

No, I didn't say anything at all to this effect.  I said that using the
RANGE clause would allow you to limit the number of initial rows in the
result set and reduce the time it takes for the initial query to run.

<< Now you're telling me that if I use the range clause, I either cannot
rely on the consistency of the data (I'm looking at the data as it was at
the time when I asked for it), or that I have to lock all other users out of
the records until I'm finished with them (with locking). >>

You need to do some more research into how databases work to understand this
in any detail, because it is fairly complicated at that level.  However, the
quick and dirty answer is that to have a non-changing source set of rows,
you need to either have long-running read-only transaction support (EDB does
not) that is supported by locking or versioning.  Most database engines use
locking for this purpose, and it is usually very restrictive and blocks
write access to the rows being read.  Versioning is less restrictive, but
also has a fairly large I/O overhead if the read-only transaction is large
and long-running.

Most database engines do not provide any sort of snapshot consistency for a
SELECT statement unless you specifically ask for it (FOR UPDATE clause, for
example), due to the above issues with concurrency and performance.  With
EDB, the rows that are read are simply read as they are encountered, and the
consistency is assumed to be enforced on the write side via transactions.
If a transaction is in effect in EDB, then the rows in the transaction will
not "appear" to readers until commit time, therefore there is never a
consistency issue with EDB if you use a transaction for multi-row updates in
the same table.  Singleton row updates are what they are.  You can also use
transaction in EDB to enforce a consistent read-only read of a table, but it
isn't recommended because it will also block any writes.

--
Tim Young
Elevate Software
www.elevatesoft.com