Planning replication

Good morning to all ...
This is my scenario:
1. We will have a central publisher
2. We will have SQL Subscribers
3. The data can be changed on the subscriber and in the publisher.
4. The central publisher will have 1 database that acts like a central
repository
for all the other suscription servers.
5. The data changes performed on the central database that belong to a
particular
server only should be replicated to that server.
Can this be done using replication ?
I have been reading about replication and "maybe" merge replication could be
a solution, but I
am not sure if the horizontal filtering will satisfy all my requirements.
Please I need some guidelines to perform this process
Thanks for any contribution,
Raul
Raul,
this can be achieved using merge. You might want to read up on dynamic
filters, as you need to filter the data depending on the subscriber. As well
as the details in BOL, you can use -HOSTNAME in the merge agent's exe
parameters to partition the data.
HTH,
Paul Ibison
|||"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:uzqUUNzcEHA.1656@.TK2MSFTNGP09.phx.gbl...
> Raul,
> this can be achieved using merge. You might want to read up on dynamic
> filters, as you need to filter the data depending on the subscriber. As
well
> as the details in BOL, you can use -HOSTNAME in the merge agent's exe
> parameters to partition the data.
> HTH,
> Paul Ibison
>
Thank you for your answer Paul ...
Please help, I have another question, What if a table in my database (The
same on publisher and subscribers) has an identity column defined, and the
same RecordID is replicated to my central server from two different
subscribers ? I have read that assigning a range for the identity fields is
one possible solution however this delimited my solution scalability, There
is another way to take care of this issue ?
Thank you,
Raul
|||Raul,
if the identity column is the PK column, then the values can't be allowed to
overlap but if it is part of a multi-column then matches are not necessarily
a problem. In the first case you can have SQL server assign ranges or
manually manage them yourself. Michael Hotek has outlined a neat algorithm
to ensure no overlaps for several subscribers, using odd and even ranges
with/without negative values etc. Either way is possible for a lot of
subscribers so isn't inherantly unscalable. Another thread today deals with
the pros and cons of guids vs identies, but generally identities are
preferred.
HTH,
Paul Ibison