No way, Alan. Station 1 gets the numbers 1001, 2001, 3001, 4001 etc, so the
1000th insert simply gets 1000001. And hopefully Fb will support 128-bit
integers by the time you reach 1/1000th of the limit for 64-bit integers ;o)

Set

At 20:25 12.12.2002 +1100, you wrote:

>uh oh, on the 1000th insert on station 1 - kapowee
>-----Original Message-----
>From: Svein Erling Tysvaer
>[mailto:svein.erling.tysvaer@...]
>Sent: Thursday, 12 December 2002 7:27 PM
>To: IBObjects@yahoogroups.com
>Subject: RE: [IBO] Re: Multiple dbs and system wide unique keys
>
>
>At 09:52 11.12.2002 -0500, you wrote:
> > >From: Alan McDonald
> > >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.
>
>I'm not favouring this solution, but your fear could be easily avoided by
>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