If you are using ASTA then you are essentially using a cached updates kind
of model.

If I were doing this, I would have each record finger printed and only allow
an update to a record that still had the same fingerprint from when I read
the record the edit is being based on. If the fingerprint was different I
would then put the update into some kind of a conflict resolution mode.

How you handle the conflict is entirely up to you. You could compare the
new record on the server to the one in the client's buffer that their new
change is based on and allow the user to consider the new version on the
server and merge in the new values, including the fingerprint, and then they
can resubmit their updates based on the new fingerprinted records.

There is no such thing as a "lock" when you are using cached updates. You
only have a transaction for updates during the resolution phase so there is
no duration of time that a lock would have an effect. That itsn't to say
you couldn't build your own locking mechanisms, but they would have to be
outside of a transaction (showing in the committed state of the data),
rather than inside of a transaction (showing as an uncommitted update
against a record).

HTH,
Jason Wharton

> -----Original Message-----
> From: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com]On
> Behalf Of jimmaguire_1949
> Sent: Tuesday, November 07, 2006 7:49 PM
> To: IBObjects@yahoogroups.com
> Subject: [IBO] Handling "Update conflicts wiht concurrent..."
>
>
> I use ASTA and IBObjects 4.5 with Firebird 1.5. I have users get
> periodic update conflicts that are resolved by refreshing their
> form/grid and retrying. I'd like a better way to handle it.
> The best
> I can come up with is to catch the exception and then give the user
> the option to either lose their changes or have them automatically
> applied by my app which would refresh repost.
>
> Is this a standard/good way to handle locks/update conflicts?