Something that occurred to me, which I am going to test, is that this lack of detecting global table changes might invalidate table locking. It occurred to me that if a session isn't checking the table for status, then it won't see any locking. So I imagine that I could apply an exclusive lock to a table to prevent access while something happens, and all lazy change detection sessions will continue to present search results as if nothing is happening at the table level.

I'm thinking there might be a big integrity exposure here. Session A locks table. Session B ignores lock, only checks record to edit to see if different from original read. Record not changed, so Session B updates in place. Session A now comes along and edits record having depended on lock to preserve data. Session B update is lost.

On 6/30/2018 10:53 AM, Arthur Williams wrote:
> Something that occurred to me, which I am going to test, is that this lack of detecting global table changes might invalidate table locking. It occurred to me that if a session isn't checking the table for status, then it won't see any locking. So I imagine that I could apply an exclusive lock to a table to prevent access while something happens, and all lazy change detection sessions will continue to present search results as if nothing is happening at the table level.

You cannot add exclusive lock if some other session has a read lock already.

Raul

Arthur,

<< Something that occurred to me, which I am going to test, is that this lack of detecting global table changes might invalidate table locking. It occurred to me that if a session isn't checking the table for status, then it won't see any locking. >>

No, that's not how it works.  DBISAM will not touch a table without first a) getting a *table-wide* read or write lock (depending upon the operation), and b) seeing if anything has changed.

Tim Young
Elevate Software
www.elevatesoft.com