Thank you very much Alan, your explanation was very clear.
Greetings.
Walter.
On Mon, Jan 7, 2013 at 8:51 PM, Alan McDonald wrote:
> **
>
>
> > Thank you very much Alan for your answer.
> >
> > How do you use dummy updates, can explain me more about that
> > technique?
> >
> > Greetings.
>
> Thank you very much Alan for your answer.
>
> How do you use dummy updates, can explain me more about that
> technique?
>
> Greetings.
>
> Walter.
>
If you get the Firebird book you will have a complete explanation. You need
to understand transaction settings little better.
In short, if you
Thank you very much Alan for your answer.
How do you use dummy updates, can explain me more about that technique?
Greetings.
Walter.
On Mon, Jan 7, 2013 at 6:32 PM, Alan McDonald wrote:
> **
>
>
> If 526 commits, then 535 will need to re-acquire before a successfull
> update,
> If 526 rol
If 526 commits, then 535 will need to re-acquire before a successfull
update,
If 526 rolls back, then 535 could proceed with existing 'stalled' edits
but the WAIT option is clumcy for the user... there's no way of knowing how
long they have to wait.
I repeat, you are better off preventing 535 from
- Transaction 510 inserts a new row
- Transaction 510 commits
- Transaction 526 start
- Transaction 526 updates the row inserted by transaction 510
- Transaction 535 start, with the clause WAIT
- Transaction 535 wants to update the row inserted by transaction 510 but
unsuccessfully because it is lo