Subject | RE: [IBO] Re: Multiple dbs and system wide unique keys |
---|---|
Author | Svein Erling Tysvaer |
Post date | 2002-12-12T08:26:52Z |
At 09:52 11.12.2002 -0500, you wrote:
setting the generator at the first location to 1, the second to 2 etc. and
then make sure you increase your generator by gen_id(<generator_name>,
1000) all the time. If there is any chance you will ever get more than 1000
locations, use a higher number. Basically it is the same as what Alan
suggested, just changing your 'Y2K scare' from #items to #locations (and
then I thought it was possible to use 64-bit numbers).
Set
> >From: Alan McDonaldI'm not favouring this solution, but your fear could be easily avoided by
> >I do this by spacing my generators - that's in fact the only difference
> >between the replicated db's, the generator for tables in dbmaster start at
>0
> >, the generator in db2 starts at 500,000,000 an so on,
> >If course this requires that insert numbers are not going to ovetake you
>and
> >that the number of DB's is within range. The next option to to make a
> >composite PK, wher ethe genrators are all the same, but the tables jn DB
> >have a db field and generator field which combine to make the pk.
>
>Alan, the first option scares me - the same type assumptions about value
>ranges for the year portion of dates lead to the infamous Y2K scare. I
>know -2 billion to +2 billion is a lot of distinct values, but I'd still
>rather not rely on an unenforcible restriction/assumption on value ranges.
setting the generator at the first location to 1, the second to 2 etc. and
then make sure you increase your generator by gen_id(<generator_name>,
1000) all the time. If there is any chance you will ever get more than 1000
locations, use a higher number. Basically it is the same as what Alan
suggested, just changing your 'Y2K scare' from #items to #locations (and
then I thought it was possible to use 64-bit numbers).
Set