Pushing data from a client to a server includes propagating the changes from Microsoft SQL Server Compact 3.5 back to a SQL Server table. For more information, see Push Method.
The application must have created the local SQL Server Compact 3.5 table by calling the Pull method with the tracking option set on.
Remote data access (RDA) tracked Pull and Push methods use optimistic concurrency control. SQL Server does not keep pulled records locked. When the application calls Push, the changes made to the local SQL Server Compact 3.5 database are unconditionally applied to the SQL Server database. This might cause changes made by other users of the SQL Server database to be lost.
Batching
RDA_BATCHOPTION specifies whether SQL Server Compact 3.5 should batch the changes being sent to the SQL Server table. The default setting is BATCHINGOFF, where changes (insert, update, and delete) are applied to the SQL Server table as individual transactions. Each transaction is not dependent on the other to succeed. BATCHINGON specifies that all changes be sent as a single transaction. In this case, all changes must succeed for the transaction to be successful. If one change fails, the entire transaction fails, and no changes are applied to the SQL Server table. While BATCHINGON is not the default option, some developers might find it as an easier mechanism to use when building resolution code for conflicts. For more information, see RDA Conflict Detection and Reporting.
Both BATCHINGON and BATCHINGOFF return all errors to the error table, not just the first error that occurs. For example, if BATCHINGON is specified and three out of five changes fail, no changes are applied and all three failures are stored in the error table. If BATCHINGOFF is specified, the same three failures are stored in the error table and the other two changes are applied to the SQL Server table.
Nonbatch Transactions
During nonbatch transactions (BATCHINGOFF option), conflicts are detected at the row level. The conflicting row is returned to the application and stored in a specified error table. For example, if the application attempts to push a row to SQL Server that is not valid, that row is returned to the application and stored in the error table along with an error message indicating the conflict.
When a conflicting row is returned to the error table, that row is removed from the original database on the device. You must design the application to allow the user to correct the conflicting data and merge the conflicting data back into the original Windows Mobile-based database.
Batch Transactions
RDA also supports a batch push (BATCHINGON option) that requires all rows to succeed for the entire push to process. If one row fails, the entire push transaction fails and no data is updated. The conflicting rows are copied to the error table. Unlike the nonbatched push, the original Windows Mobile-based database is kept intact. You must design the application to allow the user to correct the conflicting data and merge it back into the original Windows Mobile-based database. The error table is automatically cleaned before a conflicting row is copied so only the conflicts from the last push operation exist in the table.
Tasks
How to: Push Data by Using the RDA Object (Programmatically)