> I think that in a lot of cases, the simple solutions will
> work fine, if managed properly. When it becomes a problem is
> when you have ten staff in each of several offices all
> adding at the same time. Some 'create a new member' take the
> details, but the operation is not completed - the customer
> decides 'no' rather than 'yes', or a JCB digs through the
> telephone cable outside that office and the database is
> unavailble. As soon as several membership applications are
> being processed in parallel, then managing the interactions
> can be a job for the insane. A lot of users will never have
> that problem, only one person processes the applications -
> one at a time. But the database must handle the worst case,
> and Firebird does that very well. Unravelling twenty
> applications and giving them the next sequential number
> requires a little more client side support if it's needed. A
> few missing numbers is not a problem, since members die or
> resign so there will always be a growing number of holes
> anyway ( for exanmple ). It's all up to how the end user
> whats to work.

When a member is deleted and creates a hole, the next new member
fills it.

I call an SP in a transaction and lock the table for the instant I
am getting the
next sequential number. The SP adds the new record with the Id, the Id
returned for use in detail records, the transaction commits and lock
released. Any simultaneous accesses for same reason
repeatedly attempt to lock the table for the next Id until lock
released or timed out.

I have tested with 7 clients and seems to work fine.