=?Utf-8?B?RGVubmlz?= wrote in
:

So once again, how does all this caching and b-tree traversal
speed up the physical reading of a record that is not in memory.
the database engine still has to go to disk or worse yet - over
the network to get the desired record.

Well, it doesn't, but I thought your question implied that what I
was proposing was somehow going to require reading the entire table
into memory, which is patently not the case. Only as much as is
needed will be retrieved, and once retrieved that will be cached (so
that if it's needed again, there won't be another trip to
disk/server).

This is EXACTLY the way any alternative is going to work, so I just
don't see your point in disputing the question. Jet is a
random-access engine, in that it doesn't have to read the file
sequentially to get to the data, nor does it use record numbers and
offsets (as in a fixed-length record). It retrieves the minimum data
pages needed to fulfill the request, having looked up in the indexes
which are the needed the data pages. It will make the trip to disk
only once and cache the result, and go back to disk for a read only
when the record has been updated (according to the locking data,
rather than checking the data page itself).

Your question seems to me to be based on assumptions that don't take
account of how modern random-access database access works, or how
modern OS's and database engines cache and lock data.

But maybe I'm just misunderstanding your basic question.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/