Hi Jacob,

> It’s a multi-user application where multiple clients might work on the same data at the same time.

This link is to an Oracle based description, but it applies to any
multi-user database that doesn't lock records when yo read them. Be
aware that in Oracle SELECT ... FOR UPDATE .. will lock every row that
it reads, at that point, until a commit or rollback is executed to
release the locks.

Firebird works slightly differently.

http://qdosmsq.dunbar-it.co.uk/blog/2009/01/lazy-developer-syndrome-and-rowids/

(All one line by the way - in case it gets split in posting.)

> So updating history must be contained in a Transaction. I wouldn’t mind if a second user trying to update history at the same time is simply denied access. In this situation she can just wait. But the Person table shouldn’t be locked so normal work on it, like updating person records is prevented while the history updating is taking place.

Do you actually UPDATE the history table or just INSERT a copy of the
full person record as a new record into it? If the latter, then you
don't have to worry about other people inserting at the same time.

If you UPDATE, then your UPDATE processing needs to carry out the same
update precautions as the person table.

Have fun!

Cheers,
Norm.

--
Norman Dunbar
Dunbar IT Consultants Ltd

Registered address:
Thorpe House
61 Richardshaw Lane
Pudsey
West Yorkshire
United Kingdom
LS28 7EL

Company Number: 05132767