Hi nigel,

>Then you have to maintain different ranges - each installation would need to know what the ranges are (low and high). It's much more efficient to have a generic approach to assigning PKs without having constraints. A single duplicate could cause a big headache.

Yep this is a drawback, however I don't like the 128 bit (16 bytes) PK value either. It consumes too much memory.

The drawback can be reduced if each remote location has a certain number (let's say 1 - 256) and make this part of the PK, then we still have 24 bits per location to generate PKs in order to keep our PK limited to 32 bits. If this is not enough, we still could double the PK lenght and go for 64 bit.

Walter,

>>Hi nigel,
>>
>>>If you're not in a LAN environment using remote workstations, this is the ideal situation to allocate PKs without being able to refer to a central database. The data could then be transmitted daily to the central store and collated with no problems of conflicting keys.
>>
>>Yep, this is a good argument, however if the number of remote databases is limited it could also be solved by defining other PK ranges for the remote workstations.
>>
>>Thanks,
>>
>>Walter,