Lester Caine wrote:

Thanks for your reply.

>
> > 5. Edit left table:
> > Change 'a' to 's'
> > Post it
> > Commit-retaining the left table.
>
> 's' is committed
>
> > 6. Edit right table:
> > Change 'a' to 'b'
> > Post it
> > Commit-retaining the right table.
>
> 'b' is committed - right table just never sees the 's'

I understand and agree it is as expected.

The following was for

"Now change tr1 and tr2 to have RecVersion = True
and set PessimisticLocking to True in both
qryMaster1 and qryMaster2."

so I expect a deadlocks to occur.

>
> --------------------------
> > 5. Edit left table:
> > Change 'a' to 's'
> > Post it
> > but do not Commit.
>
> 's' is 'work in progress' and not committed, so no one else
> can commit until this it committed or rolled back.
>
> > 6. Edit right table:
> > Change 'a' to 'b'
> > Post it
> >
> > *Deadlock* as required.
>
> As required - no problem

I understand and agree it is as expected.

>
> --------------------------
> > 5. Edit left table:
> > Change 'a' to 's'
> > Post it
> > and commit-retain.
>
> 's' is once again committed
>
> > 6. Edit right table:
> > Change 'a' to 'b'
> > Post it
> > Commit-retain
>
> So 'b' can be committed again
> Retain just keeps the query open, but a refresh of right
> table after step 5 would show the 's'.

> > If none of these are bugs, then the GSG needs to be corrected --- or explained
> > more clearly.
>
> What exactly is wrong with the GSG? Once a change is
> committed, other changes can be committed. While a change is
> held open, other changes are not allowed.

In the GSG: "Transaction Terminology"

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

The problem is that the GSG states there will be no loss of updates
to transactions committed by other simultaneous transactions.

Therefore, with
RecVersion = True
and
PessimisticLocking = True

I expect that there will be no loss of updates, that a deadlock
will occur with an exception preventing the loss.

> If you are expecting to be told that the record has been
> changed, then you will need some additional checks,
> depending on your requirements. I timestamp some changes
> when I want to ensure that the current version of a record
> is in use - but I am working across a slow network as well ;)

The problem is not that the record is in use.

The problem occurs when the record has been committed and an
update occurs that overwrites that record without warning.

From what Helen wrote recently, I understand and accept
every case except this last one.

Raymond.