If I can jump on the bandwagon here

Developers must realise that there is a place under the sun for everyone.
Do not ever dismiss any approach without understand the business logic.

A good reason to not use Integer based generators is in the case where data
needs to be replicated to other databases, and the primary keys need to
remain unique across multiple databases. And don't tell me to use another
composite key on other compositely "unique" fields.

I used to work for a project where replication was enabled and the primary
keys were generated integers, and there was no guarantee that your keys
would be the same if one of the databases lost replication sync. (Thus the
generators might be too far or not far enough advanced). Eeeaaauuwww.

One approach would be to allow for sequences of generator numbers, however
on 2000 installations 4 billion integer values suddenly decrease to only 2
million records per database, which is not enough by far.

Donald Klopper

-----Original Message-----
From: Tim Ledgerwood [mailto:tim@...]
Sent: Thursday, January 15, 2004 7:47 AM
To: firebird-support@yahoogroups.com
Subject: Re: [firebird-support] Store procedure hangs clients ??


I agree 100% with your approach. I have several applications where the user
either chooses or assigns a number of some kind (a membership number, or a
stock code, or an account number) These have NOTHING to do with the primary
key, which is a unique integer value created by a generator, and which the
user never sees and cannot mess with.

Regards

Tim