At 11:46 AM 2/08/2003 +0930, you wrote:

>Even then, with tiCommitted, no matter how many times the visual record is
>updated, it cannot be guaranteed to be the latest.

No, the best you will ever see in an optimistic multi-user system is "the
latest committed version" - and that's only in a ReadCommitted
transaction. If your interface has some compelling reason to "update the
visual record" the moment a change is committed somewhere else, then you've
got to code it somehow. There is nothing anywhere than can predict what is
going to happen in the next 2, 5, 10 minutes, whatever.

I hope you understand that, in tiCommitted, even though the "visual record"
is wrong, the recversion accounting on the server is right.

What you can do is use DMLCaching and have your OnDMLCacheReceivedItem
handler *invalidate* records in the buffer for which notifications are
received. Then, next time that record is referenced in any way by the
dataset, the newest version will be pulled across, e.g. a scroll into that
record will cause it to be refreshed.

If you are using CommitRetaining with tiConcurrency, your transaction won't
even know about "the latest committed version" until it encounters a lock
conflict on a DML request. The best you can get from this setup is
"whatever the latest committed version was when the original transaction
started".

>That is why I thought
>IBO should check if the latest version is being updated at the time of
>posting.

How could it do that? IB/Fb doesn't support Dirty Read, so what sort of
mechanism do you think IBO could employ to find out about uncommitted work
on the server?

What IBO can and does do is reflect the server's response to a lock
conflict. So, if your app doesn't do anything about explicit locking,
you'll get the lock conflict when you post. Your transaction settings
determine the conditions that cause a lock conflict. You can make it so
that your writes will raise a lock conflict if they attempt to overwrite
something that changed since the current transaction started. But hey! you
don't want to know about all this "theory", so I won't waste any more of
your time or mine repeating it.

If you want your application to know about a lock conflict *before* the
user gets a chance to go into edit mode, use a pessimistic lock. A
pessimistic lock will fail if another transaction has posted a change to
your record, or will succeed if not. In IBO, if a pessimistic lock fails,
your record won't be allowed to go into Edit mode. Pessimistic locks
stink, but at least they **kinda** solve the problem where the database
design fails to support a requirement for strict serialisation.

Helen


Helen