Helen Borrie wrote:

> Actually
> update <table> set Recid=Recid where Recid=Recid will do fine. It's
> pointless adding a LockedBy field to all your records, since nobody can
> read it except when the record is NOT locked - and then (by your logic)
> it would always be null. ;-)

I think the point is that you'd do that first update in one transaction
and then the final update in a second transaction. That way, if the
update fails to update a record, you could also get the name of the user
who has the record locked.

Personally, I'd go with Kjell's original solution of putting the locks
in a separate table. You'd just make the record_id the primary key on
the lock table so that if you tried to insert a new record after
somebody else, you get a primary key constraint violation.

You wouldn't have any need of a "session id", and you could add extra
fields to the "lock table" - for example, you could have "user_name" and
"lock_time", that way you'd be able to report to the user "this record
was locked by 'user' at 'date' (xyz minutes ago)".

Who says you can't add functionality while porting an application? :p

Dean.