>>>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.
>
This is correct - acquiring a lock at the page can lock >1 re\ord, even if only one record is needed for update, forcing othersn to wait for the page lock to release to access the records on the page. OTOH, It makes manipulation and reorganization of data on a page easier, which makes variable-length nthingsn easier to accomodate. Knuth and Date (another database heavy) discuss allocation and lock strategy in some detail in some of their books.
>What do you think of FoxPro's locking scheme with respect to giving it a speed boost over page locking?
I'm happy with the lock granularity available under program control; I'd like it if VFP could decide to aler lock granularity based on circumstances, making page locks based on internal heuristics. It might be doing that under the hood at times, but the same capabilities might not be exposed directly to the DML part of VFP.
>
>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,
