Well you could simply use a coded IDENTITY or similar. By coded, I mean
generating the new ID in a central table, and on each server the identity
seed is different, e.g. on central it starts at 1, on remote it starts at
something like 2000000 or some reasonably large number that you won't get to
in central. INTs are big and BIGINTs are bigger; for the latter you could
spread the numbers out over a million servers and still have plenty of room
to grow for just about any business model. In addition to ensuring
uniqueness, this way when you replicate data back to central, you know which
rows were created on the remote system (which a GUID wouldn't tell you).

However, now that I mention GUID, I am thinking about one of your final
comments. If the systems cannot talk to each other, and regardless of what
methodology you use for your surrogate key, what are you going to do to
consolidate when the remote server creates a new row where the six columns
are the same as a row that already exists in the central database? (Even if
you are using replication, let's say that row was created just before the
server went down, and the row was never copied to remote.) You can't
prevent the new row from being inserted, because you don't know such a row
already exists!




"AG" <NOSPAMa-giam@newsgroups.nospam> wrote in message
news:uxVTMTHkIHA.5724@TK2MSFTNGP03.phx.gbl...
>I would appreciate some advice on generating a PK and/or synchronizing data
>between two (maybe three) locations.
>
> Simplified scenario.
> Using SQL Server 2005 (could got to 2008 if needed).
>
> Client has two locations (central and remote).
> Item record would containseven fields - six int fields (id's from
> component tables) and a seventh field that would be the PK.
>
> Most of the time the PK would be generated at central, however, should the
> connection be lost, remote must be able to generate a PK also and then
> when connection is restored, any new PK generated by remote must be added
> to central.
>
> The PK needs to be the same for the same combination of the six fields, no
> matter which server generated it, in case both servers happened to create
> a record with the same six fields. Therefore using a GUID would not work.
>
> Since the PK will be used by another system (Great Plains), it's length is
> limited to 30 characters.
>
> --
>
> AG
> Email: discussATadhdataDOTcom
>