OK Martin, if you insist on using the BDE (I don't know the
transaction part of it, but assume it has limited support for
concurrency). What about a separate table with the same primary key as
the one you want to lock? If you insert a record with the PK into this
table every time you want to lock a record, then surely this has to
fail for all but the first case that wants to update. Of course, you
have to delete the record again after finishing your update, as well
as have some kind of manual unlock/delete procedure (and/or nightly
deletes from the lock table) for use whenever the program finishes in
a non-orderly way. But it should change your problem from allowing too
many updates to allowing too few.

HTH,
Set

--- In firebird-support@yahoogroups.com, "Martin Dew" wrote:
> Set,
>
> Thanks for the reply. Unfortunately I am using the BDE for the app,
> I do not have the time to convert or go through a rigorous testing
> phase to implement IBX etc.
>
> The main problem appears to me that both users in this scenario are
> able to get an N returned by the stored proc, I need to be able to
> avoid this in some way using the existing architecture within the
> app, or else both people get the same record open for editing, and
> in the environment that my app works in this is NOT a good idea. I
> need to stop the 2nd user from being returned an N, but cannot work
> out how to guarantee this from happening. Perhaps my model of
> locking is not very good and someone else could offer an alternative
> approach (that still uses the BDE type of connection).
>
> T.I.A
>
> Martin