Alternative to Merge Replication?

Is there a simpler alternative to merge replication? I am concerned about the splash of GUID across the DB, performance issues, and the complexity of the deployment.What version of SQL server are you using? Look into transactional and peer to peer replication. FYI, these will require a primary key field to be set on each table.|||I am using SQL 2005. Your solution does NOT require a GUID?|||Correct, but it does require every table to have a primary key. You will need to read more on both technologies to determine what works best in your environment.|||Sorry, meant to post this earlier...

Info about the different types of replication, http://msdn2.microsoft.com/en-us/library/ms152531.aspx|||

there are many articles and whitepapers about replication deployments on the net, maybe we can ease you if you describe your scenario and deployment concerns. i.e. how many subscribers are we talking about?

as far as GUIDs, if you specify correctly column lists for all your insert statements, you shouldn't have any application breaks, it should be seamless.

|||

My scenerio is:

Networked offices with 5-30 internal users, modifying a central DB in SQL Server 2005

1-6 Field workers who need to modify a subset of the tables in the field (disconnected) and then connect to the network and upload their changes.

Low (though possible) change of conflicting changes between syncs, as field people tend to work in different areas. Field device might be away from the central DB for 1-10 days.

Last-one-wins would be OK for conflicting changes. I've been considering a home-grown system that inserts new records to the central DB, when executes an Audit trail for the changes.

I know it sound like Merge replication. I'm not sure why I'm so afraid of actually using Merge replicaiton. It seems so complex, and heavy, and trigger happy, and if something goes wrong it looks like a nightmare to troubleshoot.

|||

According to http://msdn2.microsoft.com/en-us/library/ms151718.aspx, Updatable Subscriptions for Transactional Replication DOES require a GUID. "Replication adds the msrepl_tran_version column to published tables for tracking purposes"

And Peer-to-Peer seems to be for Server-2-server, not for Server-2-DisconnectedClient.

|||

Peer 2 Peer does not currently handle conflicts (it will in the next version of sql server), so you can count that out for now. Merge replication does exactly what you need, there are many many references to customers using Merge replication with hundreds, if not thousands, of subscribers. My only suggestion to you is to try it out in a test environment. Yes it does require guid columns on every table as that is the mechanism used to track changes.

If you can be patient, you can also wait for OCS to come out early next year with the next release of Visual Studio, you can read about it on steve lasker's blog, search for OCS http://blogs.msdn.com/stevelasker/default.aspx.