Subject | Re: [IBO] Steps to reproduce possible bad bugs |
---|---|
Author | Lester Caine |
Post date | 2003-08-11T11:48:42Z |
> 5. Edit left table:'s' is committed
> Change 'a' to 's'
> Post it
> Commit-retaining the left table.
> 6. Edit right table:'b' is committed - right table just never sees the 's'
> Change 'a' to 'b'
> Post it
> Commit-retaining the right table.
--------------------------
> 5. Edit left table:'s' is 'work in progress' and not committed, so no one else
> Change 'a' to 's'
> Post it
> but do not Commit.
can commit until this it committed or rolled back.
> 6. Edit right table:As required - no problem
> Change 'a' to 'b'
> Post it
>
> *Deadlock* as required.
--------------------------
> 5. Edit left table:'s' is once again committed
> Change 'a' to 's'
> Post it
> and commit-retain.
> 6. Edit right table:So 'b' can be committed again
> Change 'a' to 'b'
> Post it
> Commit-retain
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 explainedWhat exactly is wrong with the GSG? Once a change is
> more clearly.
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