In IBX You have an explicit transaction for each dataset. You can either:
1) using another query in the same Transaction and attempt to do a non data
changing update, this gives you a pessimistic lock on the record. This is
fine if the chance of hitting cancel (i.e. not electing to save your
changes) is very low. e.g. update tbl set somefield = somefield where PK =
:pk. This will stop another user from making any changes to the record.
2) You can let the user attempt to make the update, when the go to post the
changes you will get an update conflict.

The important thing here is that the transaction that is used to get the
data that the user sees is the same transaction that is used to update the
data, this guarantees that either the data has not been changed by another
user or your update will fail.

HIH
Jason Chapman
JAC2 Consultancy

Training - Development - Consultancy
Delphi, InterBase, Firebird, OOAD, Development lifecycle assistance,
Troubleshooting projects, QA.....
www: When I get round to it....
Mob: (+44) 07966 211 959 (preferred)
Tel: (+44) 01928 751088


""Stevio"" <redeagle@...> wrote in message
news:017101c23a22$4e0d78c0$0300a8c0@......

> Hi Dimitry,
>
> This testing of the record for updates is exactly what I need, but I'm

using

> Interbase Express components (I should have said that in the first email).
> How can I test the record for changes before posting it?
>
> Thanks,
> Stephen
>
> ----- Original Message -----
> From: "Dimitry Sibiryakov" <SD@...>
> > >What I would like to happen is that the changes by the second user are
> > >rejected, or at the very least they are given a warning to say that
> > >this record has been updated since they opened it and do they want to
> > >go ahead with their changes.
> > >
> > >How do I do this? Can this be controlled through transactions?
> >
> > If the second user uses "read commited" transaction, then you can
> > test the record for changes before sending UPDATE. If record has been
> > changed you may do anything you want: warn user, mix changes, reject
> > them and so on.
> > The way to do it depends on BD access components. For BDE, for
> > example, UpdateMode = upWhereAll is enough to reject second user's
> > work. I guess you are a programmer, aren't you? Everything is on your
> > fingertips.