> It is really that simple - an user has to enter records of
> transactions (acually, something like a sales bill), that is of a
> certain type ("TYPE" field), and for legislative reasons the
> sequence numbers (the "ID" field) must be sequential, and resilient
> to multi-user input problems. I'm using Delphi 7 and Firebird 1.0.3.
>
>

Does it matter to the person entering the data of the sales bill, that they
know the ID of the bill as they enter it? They can enter the type presumably
but the ID can often remain greyed out in the entery form until a commit is
actioned.
This form of data entry is typically why you need a non-business related PK
in the table. One the user doesn't know about or care about. It's just thre
for uniqueness and record identification. It's an integer pure and simple.
Now when they hit the button to enter a new bill, the new PK is generated
but noone sees it. The form is ready to fill in. They fill it in. When they
hit the save button, the generator on the server creates a new ID and the
form is now filled with the next available ID and is auditable as such. If
they cancel their input, the ID field is never generated so you never
increment it and the next one is there for when you next commit.
In this scenario, the PK I'm talking about may end up with gaps but as I
said, noone ever sees it - you know it's there but noone else does.

Alan