Hi:

This problem originated from a credibility issue. Members of this "association" were
being assigned Id numbers which just kept getting bigger and bigger. This association
was started in 1974 and it had active member id's like: 1, 73, 122, 123, 287, ......
All the missing numbers were members who cancelled or moved to Jakarta or Miami. Just
kidding. Anyway, these folks wanted to know why they just couldn't have 1,2,3 etc,
etc. The explanations fell on deaf ears.

> The only way I got something like this to work was using a Generator to
> populate the primary key and another one as the "reference-name-key"(wierd
> name, but I believe that it illustrates the use).
>
> It worked like this, when populating the tables at the user entry level, a
> generator was used to give me the primary key (ex: 10), after all the fields
> and whatever else was ok, and only when I confirmed that it was going to be
> a valid entry, I fetched a number from the "reference key generator". The
> only part that is annoying is that when the users wanted to find something,
> I had to fetch the master record to find out what is value of the original

That is exactly what most everyone in the BCB Interbase NG told me to do. It seemed
like an unnecessary duplication of effort to first get a gen_id key then look up the
next sequential real Id. Seemed only logical to use the real Id as the key. They said
I couldn't do it that way and it would cause all sorts of lock conflicts and duplicate
key problems. No such problems in testing it.

The way I ended up doing it seems to work fine.

Best regards