Hi again Bob, (et all)

I've decided to impliment a semaphore locking scheme and would appreciate your thoughts.

The one approach I've thought of is the following:

1. Add an extra field to the parent table of C(10) which would be updateable.
2. When the user chooses to modify, REFRESH() current record and check if EMPTY(locking field)
3. If !EMPTY() inform user and disallow modification.
4. If EMPTY(), REPLACE locking field with user name and TABLEUPDATE()
5. When saving remove user name from locking field before TABLEUPDATE(s)
6. If user chooses to abandon changes, TABLEREVERT() and then remove user name from locking field and TABLEUPDATE.

I would appreciate all thoughts on this and ways others have implimented this type of scheme. TIA

>>Hi Bob,
>>
>>Can you please expand a little on your semaphore locking scheme idea. One of the things I thought of was like this but one stumbling block was, what if a user had a record flagged as locked and then suffered some sort of computer crash? The flag would still exist?
>
>Yep... it would. You could either implement a timeout feature, or provide a method for an admin person to reset the flag, or delete the sephamore... Also, wouldn't the same user go back into the record to continue what they were doing.
>
>You could also have something at the beginning of your ap startup that deleted all sephamores for that user when they connected.
>
>Of course, another thing you could do is use Record Locking... which is supported in SQL 7.0, but not all other back ends.
>
>Another thing you could do is start a transaction when the user went into edit mode.
>
>But, I think a sephamore table would be the best idea. The possobility of a user crashing after putting a sephamore in the table is small and something you can deal with.
>
>BOb