i wanna do Replication

Hi,
I am very new to replication . Can anybody give some initial steps to do it.
regards Ar
There are very good descriptions in Book On Line under replication. You can
look it up on MSDN if BOL is not installed
--
Mary Bray [SQL Server MVP]
Please only reply to newsgroups
"AR" <aneesh.r@.eostek.com> wrote in message
news:%23TyjB$B3EHA.4028@.TK2MSFTNGP15.phx.gbl...
> Hi,
> I am very new to replication . Can anybody give some initial steps to do
> it.
> regards Ar
>
|||On 2004-12-07, Mary Bray <no@.spam.com> wrote:
> There are very good descriptions in Book On Line under replication. You can
> look it up on MSDN if BOL is not installed
Where is in BOL explained what tables to put in publication? The design
philosophy of replication. Why to have several instead of one publication,
etc, etc, etc.
I find BOL extremley useful when you know what you're looking for. But I
dont' think that MSSQL concepts are well explained.
Mike
"I can do it quick. I can do it cheap. I can do it well. Pick any two."
Mario Splivalo
msplival@.jagor.srce.hr
|||This is a good observation on BOL. Its like a dictionary, great as a
reference, but not very good when you are tying to learn a language.
In general you put all the tables you want to replicate in a single
publication. However, you may want to seperate the tables into their own
publications for administrative, logistical, performance or deployment
reasons.
All tables related by pk fk relationships should be in the same publication.
Large tables could be in seperate publications as if the snapshot fails you
only have to resnapshot and deploy the large table, rather than starting
from scratch again. If you group your tables by DRI, use the independent
agent option, you could have multiple publications deployed to a single
subscriber with multiple distribution agents which will lead to performance
increases.
Hilary Cotter
Looking for a SQL Server replication book?
Now available for purchase at:
http://www.nwsu.com/0974973602.html
"Mario Splivalo" <majk@.fly.srk.fer.hr> wrote in message
news:slrncrbe33.360.majk@.fly.srk.fer.hr...
> On 2004-12-07, Mary Bray <no@.spam.com> wrote:
> Where is in BOL explained what tables to put in publication? The design
> philosophy of replication. Why to have several instead of one publication,
> etc, etc, etc.
> I find BOL extremley useful when you know what you're looking for. But I
> dont' think that MSSQL concepts are well explained.
> Mike
> --
> "I can do it quick. I can do it cheap. I can do it well. Pick any two."
> Mario Splivalo
> msplival@.jagor.srce.hr
|||On 2004-12-07, Hilary Cotter <hilary.cotter@.gmail.com> wrote:
> This is a good observation on BOL. Its like a dictionary, great as a
> reference, but not very good when you are tying to learn a language.
> In general you put all the tables you want to replicate in a single
> publication. However, you may want to seperate the tables into their own
> publications for administrative, logistical, performance or deployment
> reasons.
> All tables related by pk fk relationships should be in the same publication.
> Large tables could be in seperate publications as if the snapshot fails you
> only have to resnapshot and deploy the large table, rather than starting
> from scratch again. If you group your tables by DRI, use the independent
> agent option, you could have multiple publications deployed to a single
> subscriber with multiple distribution agents which will lead to performance
> increases.
>
But, how do I make initial snapshot to create foreign key constraints to
tables that aren't in the publication?
For instance, i have these 'key' tables:
l_tax_rates
l_orgs
l_stocks
l_curr_rates
l_banks
l_accounts
...
All of those are rarely changed. Updates are almost never to be happened,
inserts maybe once a year. I put all of those in snapshot replication, and I
have as many subscriptions to that publication as much as I have
subscribers.
Then, I have other tables that are related to above mentioned tables.
Invoices, stock documents, financial stuff of various names I'm unable to
say even in croatian.
When I put those tables in publication, initial snapshot won't create
foreign key constraints to the tables in snapshot publication. I'm not sure
how to avoid this. I'm setting the snapshot options of a merge publication
so that the snapshot leaves the tables on subscribers as they are. So, I
need to take care that tables all have rowguids, that all have constraints
(with NOT FOR REPLICATION option, of course), and that they're empty. Only
aster that I can push the initial snapshot and enable merge replication.
Or is there a better way?
Mike
"I can do it quick. I can do it cheap. I can do it well. Pick any two."
Mario Splivalo
msplival@.jagor.srce.hr
|||If the tables are in the subscriber independantly but not in the publication
and you desparately want the FK relationships set up, you can create a
script that runs post snapshot to do the FK creation.
Have a look at "Executing Scripts Before and After the Snapshot is Applied"
in Books-On-Line!!
--
Mary Bray [SQL Server MVP]
Please only reply to newsgroups
"Mario Splivalo" <majk@.fly.srk.fer.hr> wrote in message
news:slrncrbp3t.360.majk@.fly.srk.fer.hr...
> On 2004-12-07, Hilary Cotter <hilary.cotter@.gmail.com> wrote:
> But, how do I make initial snapshot to create foreign key constraints to
> tables that aren't in the publication?
> For instance, i have these 'key' tables:
> l_tax_rates
> l_orgs
> l_stocks
> l_curr_rates
> l_banks
> l_accounts
> ...
> All of those are rarely changed. Updates are almost never to be happened,
> inserts maybe once a year. I put all of those in snapshot replication, and
> I
> have as many subscriptions to that publication as much as I have
> subscribers.
> Then, I have other tables that are related to above mentioned tables.
> Invoices, stock documents, financial stuff of various names I'm unable to
> say even in croatian.
> When I put those tables in publication, initial snapshot won't create
> foreign key constraints to the tables in snapshot publication. I'm not
> sure
> how to avoid this. I'm setting the snapshot options of a merge publication
> so that the snapshot leaves the tables on subscribers as they are. So, I
> need to take care that tables all have rowguids, that all have constraints
> (with NOT FOR REPLICATION option, of course), and that they're empty. Only
> aster that I can push the initial snapshot and enable merge replication.
> Or is there a better way?
> Mike
>
> --
> "I can do it quick. I can do it cheap. I can do it well. Pick any two."
> Mario Splivalo
> msplival@.jagor.srce.hr
|||On 2004-12-08, Mary Bray <no@.spam.com> wrote:
> If the tables are in the subscriber independantly but not in the publication
> and you desparately want the FK relationships set up, you can create a
> script that runs post snapshot to do the FK creation.
> Have a look at "Executing Scripts Before and After the Snapshot is Applied"
> in Books-On-Line!!
Where do I enter the srcipt I want? In create publicatino wizzard there is
no option for doing so.
Mike
"I can do it quick. I can do it cheap. I can do it well. Pick any two."
Mario Splivalo
msplival@.jagor.srce.hr