Myles Wakeham wrote:

> What are the best strategies to use to accommodate this situation?

I will not repeat the situation, and I expect several other answers, but
the simple one is - Transaction Control.
You don't want people blocking things over lunch, so anything they leave
open should be shut down. The nice thing about Firebird is that in
normal use it simply does not fall foul of bad design ;)
Most of the time I just copy the data locally, and generate an update
SQL when the user needs to post a change. If three people are updating
the one record, the last one posting wins, not ideal, but perfect for my
type of application. In most cases the chances of a train being in two
places at once are remote ;)
Where I do want to 'lock' things, I write to an 'updating' flag, and add
the userid for the person who is currently working on the record. While
set, other users just get a message if they try and edit the record, and
are told who has it open. There are a couple of ways of clearing the
flag, a global clear, and a clear when that user logs off, but normally
the record is updated and saved resetting the flag.
Add Transaction Control, and when the change to the update flag is first
made, the record is flagged with a pending change, but the commit does
not happen until the changes are made later. Another user is blocked
from modifying the record, but you don't know who by because the
uncommitted change to the flag can't be seen.
Many ways to do it without 'locking'.

--
Lester Caine
-----------------------------
L.S.Caine Electronic Services