Helen Borrie wrote:

>
> At 05:10 AM 1/08/2003 +0930, you wrote:
> >With tiCommitted the Grid
> > shows and old value that has been changed and committed by another
> > allows post of new with no warning
> >
> >With tiConcurrency the Grid
> > does not allow refresh of new values provided by another
> > cannot update
> >
> >What do I have to do to have:
> > Edit a changed field causes a PreviousValueChanged message
> >and
> > Allows refreshing of the row?
> >
> >I have separate transactions for each query.
> >
> >With a single user and one application, is it necessary to also have separate
> >connection components on the form for each query?
>
> Not only unnecessary, but undesirable - except under multi-threading
> conditions, where you would instantiate a Session + Connection +
> Transactions + Queries bundle for each instance of a thread and destroy it
> when the thread finished.
>
> >Does using CommitRetaining cause the inability of tiConcurrency edits to not
> >be visible to another user?
>
> Ummm (trying to process those double negatives...)

(I like your gentle way of pointing out my double-negative.)

>

...

> In the case of tiCommitted with CommitRetaining, the original transaction
> context is still preserved, but the difference is that the transaction gets
> a constantly updated view of the records that are updated. However, you
> won't see those updated records in your *grid* unless you deliberately
> cause them to be fetched from the server. As you are no doubt aware, IBO
> has a number of ways to synch the buffers with the database in these
> conditions, without *necessarily* performing a full requery.

I am aware of it, but what steps need to be taken to make it happen?

>
> >Why doesn't a tiCommitted change using CommitRetaining by one user not
> >cause a RecordVersionChanged message by a 2nd user when changing the value
> >in the field?
>
> It's not clear where you think a "RecordVersionChanged message" would come
> from, or arrive to. There is no way that the server can detect that a user
> is editing a value in a field. When your user is doing stuff in an "edit
> mode" (I/U/D), it is all happening in the application. Post is the first
> client-side action that the server responds to. That's the first point at

User A has committed a change that user B could see if only user B would
re-query.

When IBO sends the changed record to the server, the record on the server
has a new record version to the one that is being updated by IBO.

At this point, is IBO able to detect that there is a later record version
and disallow the change?

Thus user B could see commmitted changes, but is not aware of them, and
is not made aware of them by the server when a new version is supercede
a version created after user B's version appeared on the screen.

The problem is that 2 people could change an address at the same time
without warning with tiCommitted. Refreshing is inadequate as the
changes user B makes could be over-ridden by user C, who sees what
either user A or user B sees.

I don't need to understand how it all works, but rather the steps and
settings to use to achieve my goal. So, if I have made my requirement
clear, what are those steps and settings?

In the tutorial on transactions supplied with IBO, the same thing occurs
when tiCommitted and CommitRetaining are used.

Does this mean that CommitRetaining is to be avoided completely within
a multi-user environment? What must one do to make it useful within the
context of my requirement.

> which the server can deal with a lock conflict. How it responds to a lock
> conflict depends on the attributes of the transaction.
>
> The situation with an optimistic locking system is that readers can see a
> version of every record that is in the scope of their SELECT
> specification. The version they see is the most-recently committed
> version, in the context of their transaction.

What must be done in IBO to ensure that changes are only made to the
latest version?

> -- With tiConcurrency + CommitRetaining, the transaction continues to see
> the recversions it saw 'way back when StartTransaction was first called,
> plus the updated view of any records that this transaction has changed.

> -- With tiCommitted, the transaction's view (what the server will allow it
> to see) gets updated each time another transaction commits a change to a
> record that this transaction can see -- even with
> CommitRetaining. However, the client buffers won't get updated unless you
> deliberately update them - so, when you're thinking about "what's in the
> grid", you're not thinking about "what's happened on the server" unless you
> deliberately synchronise the dataset's buffer with the Read Committed
> transaction's latest view.

Even then, with tiCommitted, no matter how many times the visual record is
updated, it cannot be guaranteed to be the latest. That is why I thought
IBO should check if the latest version is being updated at the time of
posting.

There's a piece to the puzzle that I do not have yet, and that is why I
have described what I want to do and requested the steps to achieve it,
rather than continue to discuss all the possibilities in theory.

Raymond Kennington