benefits/disadvantages of activex/sql-dmo

i have just setup my main sql server as a central publisher/distributor and a number of laptops (only connect to network once a week) with msde as annonymous pull subscribers, using merge replication. Using windows synchronisation manager i have run the c
ommon conflicts i expect to occur and everything works ok.
Could anyone tell me the benefits/pitfalls of using SQL Merge Control or SQL-DMO, over Windows Syncronisation Manager?
Is there a way during syncronisation to determine which side publisher/subscriber has priority on each conflict as and when they occur?
Please bear in mind this is the first time I have worked with SQL Server and I am the only IT person in a small company so I am avoiding over-complicating things for users as much as possible. These message boards are brilliant for advice from people more
experienced than me.
Thanks for your help
SQL DMO is what the replication wizards use. Under the covers it runs replication stored procedures.
Think of the Active
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"James P" wrote:

> i have just setup my main sql server as a central publisher/distributor and a number of laptops (only connect to network once a week) with msde as annonymous pull subscribers, using merge replication. Using windows synchronisation manager i have run the
common conflicts i expect to occur and everything works ok.
> Could anyone tell me the benefits/pitfalls of using SQL Merge Control or SQL-DMO, over Windows Syncronisation Manager?
> Is there a way during syncronisation to determine which side publisher/subscriber has priority on each conflict as and when they occur?
> Please bear in mind this is the first time I have worked with SQL Server and I am the only IT person in a small company so I am avoiding over-complicating things for users as much as possible. These message boards are brilliant for advice from people mo
re experienced than me.
> Thanks for your help
>
|||sorry that last message was send prematurely.
Think of the ActiveX controls as a lightweight version of SQL DMO. Windows Synchronization Manager uses the ActiveX controls.
Here is a brief rundown of the differences. BTW - I only use SQL DMO, although its more complex to code with, it is more feature rich.
1) If you are building publications, you must use SQL-DMO. You cannot build publications or push subscriptions with ActiveX replication controls.
2) The ActiveX replication controls' functionality is limited to copying subscription databases (but not attaching them), managing the Snapshot and Distribution Agents, creating pull subscriptions, and reinitializing subscriptions.
3) Despite their limitations, the ActiveX replication controls have proven to be far more popular than SQL-DMO is as they contain only three classes, and are simpler to work with .
4) you can't control the ActiveX agents through the agents folder in EM.
To answer your specific question regarding priority in SQL DMO its the priority property of the MergePublication class, in ActiveX its the SubscriptionPriority and SubscriptionPriorityType of the SQLMerge class.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"James P" wrote:

> i have just setup my main sql server as a central publisher/distributor and a number of laptops (only connect to network once a week) with msde as annonymous pull subscribers, using merge replication. Using windows synchronisation manager i have run the
common conflicts i expect to occur and everything works ok.
> Could anyone tell me the benefits/pitfalls of using SQL Merge Control or SQL-DMO, over Windows Syncronisation Manager?
> Is there a way during syncronisation to determine which side publisher/subscriber has priority on each conflict as and when they occur?
> Please bear in mind this is the first time I have worked with SQL Server and I am the only IT person in a small company so I am avoiding over-complicating things for users as much as possible. These message boards are brilliant for advice from people mo
re experienced than me.
> Thanks for your help
>