Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
samrat
Yak Posting Veteran
94 Posts |
 Posted - 2002-02-13 : 20:24:11
|
| In order to achieve only one directional replication through merge replication (Ie from Publisher to subscriber) i changed the command syntax of merge agent in its properties by adding -ExchangeType 1. But some how this doesn't seem to work !!! Can any advice of a possible cause .Cheers,Samrat Valani |
|
|
DavidD
Yak Posting Veteran
73 Posts |
Posted - 2002-02-13 : 21:43:17
|
| If you want one way replication use transactional replication rather than merge replication. Other articles that require 2 way can use merge replication - it is fine to use both. I should warn you though if you are using merge replication over phone lines and have more than a handful of subscribers, the overhead required for SQL server replication will become more than the phone lines can cope with very quickly and the process will fail. If your T-SQL is OK I suggest you write the process yourself using distributed transactions, triggers and stored procs, it is a bit of a pain, but at least it will work. |
 |
|
|
samrat
Yak Posting Veteran
94 Posts |
Posted - 2002-02-13 : 23:16:38
|
| Thanx for the tip david. !!David in the scenario that i am trying to work on, I would have more then handful subscribers for my database. But i am not sure abt what u exactly meant by writing the process by myself..Can you please explain me with an example Regards,SamratSamrat Valani |
|
|
|
DavidD
Yak Posting Veteran
73 Posts |
Posted - 2002-02-14 : 19:08:37
|
| Samrat, This is very basic, but if you establish a Changed database which is written to via triggers in your main database. These triggers would go something like this:Create trigger Sales_Insert as insert into Changed.dbo.Sales (fieldnames..,action) (select t.fieldnames.., 'insert') from inserted i, Sales t where i.SalesID = t.SalesIDSimilar triggers would exist for updates and deletes. This changed database would therefore keep records of what has changed and in what way. This information can then be used to update remote databases by distributed transactions. In order to create Merge replication the process may also require the use of boolean fields to determine what has already been processed and identity fields to monitor what new data was required by the remote server. Store the most recently downloaded number locally and pull everything higher than that. The distributed transaction would be in a SP which can be run as a job when telecommunicating, the sp would go something like: Insert into table localSales (select fields from remoteserver.db.dbo.sales where action = 'insert' and identity > lastidentity) Update localsales....etc Obviously this is fairly basic but hopefully will steer you in the right direction - it is a big job. |
|
|
|
|
|
|
|
|
Merge Agent - Exchange Type property