共用方式為

What ever happened to RDA?

  • 發行項

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:

  1. You’re using Identity columns.
  2. You want to replicate schema changes to the client.
  3. You want change tracking on both the client and server to perform diffs of each of the tables during a sync instead of re-downloading the entire table.
  4. You want to automatically resolve conflicts that arise when 2 people update the same data.
  5. You want referential integrity constraints to be pushed down to the client database from SQL Server.
  6. You don’t want to write code to perform synchronization or filter data.

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:

  1. Your Primary Keys use GUIDs instead of Identity columns.
  2. Users don’t overwrite each other’s data so you don’t need conflict resolution.  The rule of “Last in Wins” works for you.
  3. While you want indexes to be pushed down, you don’t care if your local SSCE database has referential integrity constraints applied.
  4. You want to wrap the changes you upload to SQL Server in a transaction so that all changes are applied or none of them are.
  5. Change tracking on the client is good enough and re-downloading updated server tables doesn’t take too long.
  6. You developers don’t mind writing some sync code.
  7. Be able to execute SQL and Stored Procedures directly against SQL Server via IIS.

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:

  1. Supports conflict resolution.
  2. Change tracking on the server as well as the client so that only data differences are exchanged.
  3. Peer to Peer sync in the forthcoming v2 of Sync Framework.
  4. Sync with databases other than SQL Server.
  5. Best suited for SSCE running on a desktop or laptop.

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:

  1. Lots of download-only lookup/reference tables that aren’t changed by the user.
  2. Tables that are pushed down to the device that tell a user where to go and what to do.
  3. Tables (sometimes empty) that are used to capture data from the user in the field that are upload-only.

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?

  1. You won’t modify SQL Server’s schema with GUIDs and Triggers.
  2. You won’t degrade the performance of SQL Server by having it track changes and maintain extra metadata.
  3. You will have the fastest and most scalable sync solution with least amount of hardware.
  4. Time to market is shorter.

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.

-Rob

Comments

  • Anonymous
    October 25, 2009
    Hello Rob Iam kind of new with mobile development, but what i understood that my company had problems with RDA in transactions and were considering replication to solve this problem, but you mentioned here that RDA solves transaction problems, can you tell me how is that possible??

  • Anonymous
    March 25, 2010
    Isn't another reason to avoid RDA that it is deprecated and should not be used for new applications? (http://msdn.microsoft.com/en-us/library/ms172917.aspx)