Why are you using merge when the data flow is in one direction. You should
be using transactional for this. Expect at least twice the amount of data
flow that hits the publisher to be applied on the subscriber. However this
can vary widely depending on how many rows are affected by each DML on the
publisher and whether text or binary data is involved.
--
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com [quoted text, click to view] "Rafael Lenartowicz" <rafaell@rcl-consulting.com> wrote in message
news:OrX0acKfHHA.1252@TK2MSFTNGP04.phx.gbl...
>I guess you should start with estimating amount of data being transfered,
>it frequency and concurrency requirement.
> the more data and more frequent and how fast you have to be "in sync"-
> replication is most likely scenario you should go with. Less data and less
> frequent - a custom app or SSIS package might do the trick...
>
> "Sas" <Sas@discussions.microsoft.com> wrote in message
> news:0F14BBEA-A720-40FF-88A3-8C7B126DBC46@microsoft.com...
>> We have production database (1TB, sql server 2005) and we will receive
>> daily
>> updates from a vendor. All the updates will be imported in another
>> database
>> first (source db). What would be the best way to apply the updated
>> information to the from the source DB to the production DB (example of
>> updates are: new products or just price changes on existing products
>> etc....). I was thinking about unidirectional merge database (src db to
>> prod
>> db) but if someone can give some suggestions it would be greatly
>> appreciated!
>>
>> Thank you all
>> --
>> --
>> System Engineer
>> MSc in CS, MCSE4, IBM Certified MQ 5.3 Administrator
>> "I saw it work in a cartoon once so I am pretty sure I can do it."
>
>
