> One mans insanity is another mans glory. I find it rather simple
> and it works fine in an app I am working on. I needed sequential
> member number. using a unique key from a gen is fine. But I also
> needed the sequential. In getting the sequential to work, there
> appeared to be no need for the gen. key.

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.

--
Lester Caine
-----------------------------
L.S.Caine Electronic Services