Subject | Re: [firebird-support] Feature request : Generator tables |
---|---|
Author | Jonathan Neve |
Post date | 2004-02-20T10:21:07Z |
Alan McDonald a écrit :
the database (this is what I meant by confirming), they issue a
gen_id(gen_name, 1). Even if they all do that at the same time, they
still can't ever get the same value, since it's a generator. They might
have the same value before the record gets inserted (this is merely in
order to show the user something, rather than the code appearing only
when they press OK), but that makes no difference. An alternative/better
method (which I often use) would be to assign a temporary (unique) code,
insert the record, and not display the code. Then, when the user
confirms, get the real, definitive value for the PK, and show it. an
example could be using a (separate) generator, and taking the negative
value.
Anyway, this is a side issue. As I said, I don't think generators, as
they currently stand, are good enough to solve the more complex usser
requirements of most database applications, or at least, not as much as
they perhaps could.
Thanks!
Jonathan Neve.
[Non-text portions of this message have been removed]
>>Yes, of course. However, there are ways to get around this problem. ForWhy would they have the same PK value? When they insert the record into
>>example, what I usually do, is first get the generator value and display
>>it, using "gen_id(gen_name, 0) + 1", and then, if and when the user
>>confirms, I actually increment the generator. This avoids all
>>concurrency issues in a simple way. However, this technique isn't
>>
>>
>
>This is a recipe for disaster me thinks - another user or many users can hit
>your client code here and be sitting on it waiting for confirmation - they
>will all have the same PK value!!
>
>
the database (this is what I meant by confirming), they issue a
gen_id(gen_name, 1). Even if they all do that at the same time, they
still can't ever get the same value, since it's a generator. They might
have the same value before the record gets inserted (this is merely in
order to show the user something, rather than the code appearing only
when they press OK), but that makes no difference. An alternative/better
method (which I often use) would be to assign a temporary (unique) code,
insert the record, and not display the code. Then, when the user
confirms, get the real, definitive value for the PK, and show it. an
example could be using a (separate) generator, and taking the negative
value.
Anyway, this is a side issue. As I said, I don't think generators, as
they currently stand, are good enough to solve the more complex usser
requirements of most database applications, or at least, not as much as
they perhaps could.
Thanks!
Jonathan Neve.
[Non-text portions of this message have been removed]