> I see this kind of housekeeping as a little downside of your
> method. The state that a record can still be marked as
> 'opened by user X' after eg. the computer of user X has
> crashed is something I would like to prevent. That was why
> I was suggesting to set the locking field and let the user
> edit the document within one transaction. This would mean
> that the setting of the locking field would be rolled back
> when the user's computer crashes.

Need nested transactions to get it working properly in my
case. That is not in FB1.5 <g>

> 1. It means a lot of work for the server to scan and update
> all tables containing documents when the user logs in or
> logs off.

I just check that 'SELECT COUNT(LOCKFLAG) WHERE LOCKFLAG =
X' = 0 - fairly fast. If not THEN I do a clear down. There
is rarely a problem, but worst case IB_SQL allows you to
clear the flag - used that a couple of time in 9 months.

> 2. You have to make sure that this 'clear all' is not
> executed when a single user has more then one connection
> to the DB. (Which is not quite difficult, I agree.)

My users are only allowed to be active on one connection. It
stops them trying to log in from two locations at the same
time ( and logs their 'working time' in the process <g> )

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