Subject | Re: [firebird-support] Re: Key violation on Primary/Unique key constraint INTEG_55/30 on table(s) |
---|---|
Author | Helen Borrie |
Post date | 2006-03-14T12:03:50Z |
At 10:42 PM 14/03/2006, you wrote:
*this* transaction, whether *that* transaction had reduced the
generator. It doesn't matter if there are gaps. Once a unique number
is generated, it should never be recycled.
transactions. That is why it is *always* safe to move them forward
in a multi-transaction environment. However, it is *never* save to
move them backwards, since you interfere with this independence.
Just don't listen to anyone who advises you to tinker with generators.
Please, would you take care to trim your messages, and not to top-post.
^ heLen
>You have killed two birds with one stone with this post!You should not even think of such an idea. You could never tell from
>
>The problem with the INTEG_55 constraint has also been solved using
>this method, by setting the TRANSCRIPTIONIDGEN value to the max value
>of the database.
>
>One question:
>
>How do I decrement the value of the Generator (without setting it) if
>I have tried to make a new person, but decided to cancel the idea.
*this* transaction, whether *that* transaction had reduced the
generator. It doesn't matter if there are gaps. Once a unique number
is generated, it should never be recycled.
>Therefore, when I press the 'Cancel' button on a form, it willNo, generator values are totally independent of all
>decrement the Generator value?
transactions. That is why it is *always* safe to move them forward
in a multi-transaction environment. However, it is *never* save to
move them backwards, since you interfere with this independence.
Just don't listen to anyone who advises you to tinker with generators.
Please, would you take care to trim your messages, and not to top-post.
^ heLen