Helen Borrie wrote:

>
> 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 don't need to see the latest version, but did expect to be prevented
from changing an earlier version than one committed since viewing the
record.

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

Yes, I do understand that. That is why I am still puzzled as to what
to do to change the tutorial on transactions so that when both
transactions are tiCommitted and a commit occurs on the left grid,
a right grid change to the same record will not be permitted.

Or is this just not possible and just not done?

Must one use tiConcurrency for this?

>From the GSG:

"READ COMMITTED enables the transaction to see all committed data in the
database, and to update rows updated and committed by other simultaneous
transactions, without any loss of updates."

In the Transaction Tutorial example, updates are lost.

So, how can the Transaction Tutorial be altered to demonstrate the statement from
the GSG?

>
> 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.

That's useful to know. However, it will still not prevent the same problem
arising when trans-type = tiCommitted.

>
> 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?

Is IBO able to check if the latest record-version is being updated?

>
> 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

Do you mean use tiConcurrency? If so, then the latest version is not
retrievable. Therefore tiCommitted with CommitRetaining is not to be
used. Right?

So, is there anything that can be done with tiCommitted and CommitRetaining
that will allow me to

(a) refresh a record to view the latest values before editing;
and
(b) be warned about overwriting a record changed since the last read;

> don't want to know about all this "theory", so I won't waste any more of
> your time or mine repeating it.

(I respect your knowledge and appreciate the time you spend on my questions,
so I though I could save you some by asking for implementation steps rather
than theory. I thought it would save you time and get me to my goal quicker.)

> 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.

What do you do to allow 2 users to simultaneously read an address record and
both attempt to edit it?

What do you use tiCommitted and CommitRetaining for in a multi-user environment?
--
Raymond Kennington
Programming Solutions
TeamW2W (InfoPower)