Geoff Worboys wrote:

> That was the point of my comment "except that we dont seem to
> store the increment as part of the generator definition".
> If the increment was part of the generator definition then
> the "standard" would be defined. That aspect is not feasible
> with the current implementation.
>
> Where are you with the new SQL standard syntax "NEXT VALUE"?
> It seems you are stuck with using non-standard gen_id. Whereas
> if the increment was part of the generator definition you could
> use the NEXT VALUE syntax.
>

The value of a variable increment is for making cluster wide unique
sequences for replication. To do this right, you need to the database
(or schema, if Firebird had schemas) to maintain both an increment and
base where the next sequence is (generator * increment + base). It is
far, far better to have the database engine do the computation than to
push it back into application. I think this could easily be implemented
in the Vulcan code base, but some thought would need to be given future
schema work, etc.

I don't see any reason why sequences/generators shouldn't be under
security control. On the other hand, I don't see any anyone in his
right mind would expose his database to malicious users, either.
Creating and committing transactions in a tight loop is probably a
better way to bring a database to its knees, though I could probably
come up with another hundred. But still, there's no reason that
generators don't have security other than history.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376