David,

I want everyone to know that I stand corrected. In my response to Bruce I
stated that no one had answered the original question in this series of
correspondences. At that point I had not read your response.

Thank you for answering the question. I also reposted the question and
Allen Browne, you, and a few other responded to the re-post and answered the
disk access speed issue.


Your comment :A Jet/ACE data store doesn't store data in records, but in
data pages. It's not like legacy systems at all. And the fields are variable
length, so records are variable length. The efficiency of interaction with
the storage and RAM are pretty moot since the days of disk caching, when even
a write is done to RAM (and then persisted to disk when convenient). This
means there's hardly any difference between RAM manipulation and
reading/writing from/to the data store, since both are happening in RAM.

Response: I can see what you are saying, but that assumes that you are
accessing data records sequentially. What happens to all that disk caching
when I am randomly reading records which I would do during data entry (which
is where I am most concerned about disk access and network speed). The user
might need the 1st rcd, then the 1,000 rcd, then the 5,257th rcd, then the
10th rcd, etc. etc.). Unless the entire table is cached, was good does
loading a data page do if the record that you need next is not on that page?
And if the data is cached in a server, that does not good all because you
have the network bottle neck.

I know about write caching and it does not affect the speed of retrieving
data (unless you do not have enough memory and your machine is thrashing),
which is why is was not part of the question.

Your comment: And when a server database is involved, the bottleneck is not
RAM vs. disk, but the network connection, which is vastly slower than not
just the RAM, but even slower than disk access.

My response: I know the network speed is MUCH, MUCH slower which is why I
made it part of the question. Remember, my original interpretation of John’s
“Fields are expensive, records are cheap” had with do with disk access over a
network versus internal CPU process. I though he knew something about
internal process of Access where Access was very slow when processing large
records. I grossly misunderstood his comment. I thought he was saying it is
better to access the disk multiple times with small records that to have one
large Access record. He has since explained his comment and now I know it
had nothing to do with disk accessing speed.

Dennis