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?

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

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?

Thanks for your help.

Regards

Bob Zirbel

--- In IBObjects@egroups.com, "Jason Wharton" <jwharton@i...> wrote:
> > I have read in other posts that 'true' client server applications
> > don't use record locking.
> >
> > How then does one prevent a user from changing a record that is
being
> > changed by another user in an interactive application?
> >
> > For example, a user is updating a customer name. Another user
> > decides to change the address. If there is no record locking how
do
> > you prevent the loss of one of the changes?
>
> What is meant by locking is doing something "in order to" change a
record.
> In InterBase you just change the record. By doing that, this
prevents
> another person from changing the record with a deadlock exception
as soon as
> they try.
>
> This is called optimistic concurrency.
>
> To make it pessimistic (like PDOX, etc.) is all you have to do with
> InterBase is perform a dummy update to the record and that
effectively locks
> it from being modified by another user. This is what IBO does for
you
> automatically if you set the PessimisticLocking property to true.
>
> HTH,
> Jason Wharton
> CPS - Mesa AZ
> http://www.ibobjects.com