> 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).

I am not clear on exactly what you mean here. But even without
that understanding...

> It is far, far better to have the database engine do the
> computation than to push it back into application.

I totally agree with this. The generator should be considered
as an object that returns appropriate "next" values. In theory
these need not even be sequential (if the generator was a more
intelligent object than it is now).

> 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.

Very few do it intentionally (I wont say that no one does it,
there are such concepts as "honey pots" in security). Here is
quote from something I was reading recently:

"accountants Ernst and Young, reports that 82 percent of the
worst frauds in 1999–2000 were committed by employees; nearly
half of the perpetrators had been there over five years, and
a third of them were managers"
(taken from "Security Engineering" by Ross Anderson).

There may be less incentive to be destructive than there is
to commit fraud, but then without knowing the applications use
of a generator you dont know if artificial increments to a
generator could be used to enable fraud.

(Replication is an interesting possibility here; could a record
be surreptitiously inserted/replaced/deleted from a database
system by changing a generator, performing some appropriate
action and then moving the generator back again. Later action
by the replication system could perhaps be fooled into
accepting changes that are not valid.)

> 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.

Of course there is very much to do in Firebird before it could
be considered in anyway resilient against attacks from
authorised users. Generators are just a very obvious example,
and one that is fast and conceivably leaves very little trace
of what may have gone wrong or why (move the generator at a
critical time and then move it back again - who is to say how
all those records ended up out of sequence or failed to get
replicated).

--
Geoff Worboys
Telesis Computing