Subject Re: [IBO] Steps to reproduce possible bad bugs
Author Lester Caine
> 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'

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

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

--
Lester Caine
-----------------------------
L.S.Caine Electronic Services