"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:
>> 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

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

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.
>

"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-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!!

"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:
>> 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