Deciding between using Remote Data Access (RDA) or using replication in your SQL Server Compact application depends on the purpose, function, scale, and requirements of your smart device application. Each connectivity data solution has different advantages and disadvantages.
Both RDA and replication are good for wireless transports. Compression is used to reduce the size of transmitted data. You can use encryption to safeguard sensitive user data during transmission.
Feature Comparison
Feature |
Replication |
RDA |
|---|---|---|
Exchange of tracked data changes |
Replicates changes to and from server and client Column-level Tracking – reduces the amount of data transferred, by only transferring changed column data Row-level Tracking – whole row is transferred |
Pushes changes from client to server only. Complete update of client data required to receive server changes. Row-level Tracking – whole row is transferred. |
Number of tables from which data can be propagated |
Multiple tables – as many as defined in the publication |
One table per RDA method. |
Types of tables that can be propagated |
Different types of tables to control data flow Addition or removal of a table in the publication (server) is replicated automatically without reinitializing the subscription on the client |
N/A Addition or removal of a table at the server is not automatically replicated to the client. |
Constraints and indexes |
Referential integrity constraints and indexes are replicated from server automatically. |
Referential integrity constraints are not replicated, indexes are optionally replicated. Additional schema definition must be defined at the client. |
Conflicts |
Conflicts include data changed by different users and rows which did not apply because of an error. Resolution and management of conflicts on server Built-in and custom conflict resolvers supported. |
Conflicts only include rows which did not apply because of an error. RDA does not detect if data was changed by a different user. Conflicts not managed, but are optionally reported in an error table on the client. No conflict resolvers. |
Schema changes |
Schema changes (such as add/drop columns, add/drop constraints, or changing column definition) can replicate. |
Schema changes are not allowed. If the schema is changed, the client must drop the table at the client and pull all the data from server again. Depending on the schema change, a push can fail. |
Identity columns |
Manual and auto identity range handling. BigInt and Int columns supported. |
Manual identity range handling. BigInt and Int columns supported. |
Data/schema definition |
Occurs at the server when the publication is configured and is automatically defined at the client when the subscription is created. |
Data and schema definition occurs at the client when data is pulled from server to client. |
Tools (UI) |
Extensive tools to create and manage subscriptions, and monitoring tools to manage multiple subscriptions, watch performance, and sync times |
No tools supported. |
Server invasiveness |
Tables and columns added to server database to manage replication. |
No changes made to database on server. |
Because of design limitations, remote data access (RDA) will be removed in a future release. If you are currently using RDA, you should consider transitioning to Microsoft Synchronization Services for ADO.NET. If you were planning to use RDA in a new application, you should instead consider merge replication or Sync Services. Note that Sync Services is currently available for both desktop and mobile devices. |