>> Credits for problems when anyone reset the generator should
>> go for who reset and/or for who designed it to be resettable.

This has always been, and continues to be, a significant flaw
in the security of Firebird. (This along with the lack of
ability to restrict creation of metadata.)

> Give me a break, fella. That was a long time ago and I didn't
> know any better. It was obvious within a year of the V3
> release that allowing them to be resettable was a major mistake.
> I've gotten smarter since -- Netfrastructure/Falcon don't let
> anyone move a sequence backward. Forward, yet, backwards, no.

I hope you are NOT suggesting a user should be able to move a
generator forward by an arbitrary amount? This is effectively
the same as allowing it to be reset back to zero. I just move
the generator forward to its upper limit.

The ONLY secure solution to the generator issue is to be able
to secure all access - as with other metadata objects. Secure
the generator and then explicitly give access via GRANT to (for
example) a trigger.

Being able to differentiate between a standard increment and
non-standard increment (except that we dont seem to store the
increment as part of the generator definition) could be a mid-
way step. You could then allow read or read/write access to
the generator. Read access would allow "next value"
(gen_id(xxx, 1)) but only write access could alter sequence.

--
Geoff Worboys
Telesis Computing

And what exactly is a non-standard increment? I have replication servers and
10 as the basic increment
Alan