Bob,

> Thanks for your reply Jason. The PessimisticLocking parameter does
> the trick.
>
> Is this the method you use in a true client server application? Or is
> there a better way?

I don't use pessimistic locking. If there is a conflict there is a conflict
and the user needs to do their whole transaction another time.
PessimisticLocking is just extra work that is usually unnecessary.

One thing you had to recall is that there were no such things as
transactions with file based databases. As a result you had to be careful
about how changes were applied so that each user's work was done as one
atomic unit. This is all built into the engine now so you don't have to
worry about it anymore. Just let all users do whatever and if something goes
wrong you rollback the whole thing and start over again. Sounds harsh but
functionally it is just much cleaner to work that way even from an end-users
point of view. If it is a long process the user goes through then of course
it should be broken up into various stages but with transactions there
really is no need to be concerned with locks.

> And, what then is the difference between optimistic and pessimistic
> concurrency?

I think I pretty much already summed it up. Pessimistic means two users
cannot go into edit mode on the same record. Optimistic means you let users
go into edit mode and are "optimistic" that another user isn't doing the
same thing.

> One last question: In the BDE the user name was returned in the
> exception message if a record was being edited. Is this still
> available?

No, unfortunately not.

Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com