Alexandre Benson Smith wrote:

>>When you scrape through the layers of the argument, it makes a great
>>deal more sense to address the actual issues, cluster unique
>>identifiers, than to support a workaround for the absense, GUIDs.
>>
>>
>>
>>
>>
>Sorry I don't follow this list for a long time, I don't know what was
>discussed about clustered unique identifiers.
>
>
>3.) Use steped values (don't know how to call this), for example one
>defines a limit of 1000 sites (individuals DB's), the generators values
>will be started with an off-set and increased by 1000 so for site 1 the
>values wil be 1001, 2001, 3001, 4001 for site 2 will be 1002, 2002,
>3002... for site 999 will be 1999, 2999, 3999 and so on. This is my
>prefered approach, since the numbers will just increase to the limite of
>a int64 and will not required human intervention, the contra is one have
>a limited numbers of individuals DB's, in my systems a gap of 1000 is
>far away what I expects to reach, I expect a maximum of 10 individuals
>DB, so a 100x bigger gap make me fill comfortable :-)
>
>

Netfrastructure computes sequences as "physicalSequence * interval +
cpuId" where "interval" is defined on a per-schema value and "cpuId" is
set at database initialization based on mac id or ip address. "CpuId",
of course, must be less than "intervalId". There are a couple of extra
rules enforced by the system:

1. A physical sequence can be set forward only, never back.
2. The interval can be increased, never decreased.
3. Back and restore handle physical, not virtual, sequences

These rules guarantee that sequence values are always monotonically
increasing and are unique cluster wide. There is no need to reserve cpu
id, although it doesn't hurt if you do, since the interval can be safely
increased at any point.

The specific rules that map mac address or ip number to cpu id are
application specific and are implemented in the class initializer for a
schema's Java class. Since Firebird has either schemas nor Java,
another scheme would be required.

>If this ensure a unique value accross multiple unconnect DB's, I will
>agree that we don't need anything else.
>
>
>
>

It works like a champ.


--

Jim Starkey
Netfrastructure, Inc.
978 526-1376