>>snip<<

>That runs contrary to my experience; if multiple records under edit reside in a single page, fewer locks are being tossed about. The issue of record locking vs page locking is one of granularity of the lock, not the efficient nature of the lock mechanism. With variable-length records, page locking offers huge advantages in terms of lock management - a pae is a fixed-size object, while a record is not, and it's harder to maintain the table of variable-sized locks in general. During data addition, page-level locking pays off well, because a single lock may siuffice for several insert operations.
>

Hmm. Must be because I had to deal with this stuff many moons ago then. The trouble we had was that when a page was locked it locked multiple records and precluded any editing therein. I can see where if one individual had multiple locks where it could be quicker. Perhaps I failed to mention that this was a situation where multiple people essentially collided in the same page.

What do you think of FoxPro's locking scheme with respect to giving it a speed boost over page locking?

BTW, thanks for the clarification vis a vis btrieve. I was apparently under the mistaken notion that it was an entirely different beast than ISAM, not a subset or variant.

Best,