Who remembers using Remote Data Access to synchronize data between SQL Server and SQL Server Compact? I certainly do!
Before I dove head first into the world of Merge Replication, I always used RDA to get my customers up and running quickly. Mobilizing an organization’s workforce quickly and easily is what it’s all about so they can start reaping the benefits. In addition to a speedy time to market, there’s no faster or more scalable mobile sync technology on the market anywhere.
So why wouldn’t I always use RDA? Here’s a quick list:
If anything on the above list applied to you, you would shift to Merge Replication because it could manage ranges of Identity columns, push down schema changes, only sync data differences, resolve conflicts and push down a database’s referential integrity constraints. Merge requires almost no code to get started and tables and columns are filtered visually via a wizard.
So why might you choose to use RDA? Here’s another list:
If your solution meets the criteria in the list above, you’re probably a good candidate for using RDA instead of Merge. Are there any other choices out there?
Back at MEDC 2007, we announced a new data replication technology for devices called Occasionally Connected Sync that would sit somewhere between RDA and Merge. OCS as it used to be called was renamed Sync Services for ADO.NET and then was eventually merged into the Sync Framework.
The Sync Framework is a developer-focused technology:
The clearest differentiation that the Sync Framework has over Merge is its provider model which allows it to sync with other ADO.NET databases like Oracle or DB2. SQL Server supports built-in P2P Transactional replication and v2 of the Sync Framework will allow you to do this via WCF. If you development team doesn’t mind writing lots of sync code and needs to support scenarios like synchronizing with other databases from SSCE on the desktop, then the Sync Framework might be the way to go for you. I wouldn’t yet recommend the Sync Framework for device sync since its wire protocol is currently based on the DataSet which may cause out of memory errors on Windows phones with limited working sets.
So where does this leave RDA?
The reason I’m writing this blog post is because time and time again I run into customer sync scenarios that don’t always need the power of Merge or the extra flexibility of the Sync Framework. Most field service applications follow the same kind of pattern:
These kinds of schemas don’t require conflict resolvers or server change tracking and are therefore well suited for RDA.
What’s the big benefit of using RDA if a sync scenario meets its criteria?
The big takeaway here is that I want you to consider your sync solution carefully before choosing a technology. If your customer’s needs are met by RDA, then you should use it and reap the benefits of developing and deploying a simpler solution with fewer moving parts.
Remember Occam's Razor.