How to: Work with Events and Program Business Logic
This topic describes how to work with events and business logic in Sync Framework. The examples in this topic focus on the following Sync Framework types and events:
The SyncAgent StateChanged event and SessionStateChangedEventArgs
The SyncAgent SessionProgress event and SessionProgressEventArgs
The DbServerSyncProvider ApplyingChanges event and SqlCeClientSyncProvider ApplyingChanges event, and ApplyingChangesEventArgs
The SqlCeClientSyncProvider SchemaCreated event and SchemaCreatedEventArgs
The DbServerSyncProvider ChangesSelected event and SqlCeClientSyncProvider ChangesSelected event, and ChangesSelectedEventArgs
The DbServerSyncProvider ChangesApplied event and SqlCeClientSyncProvider ChangesApplied event, and ChangesAppliedEventArgs
The DbServerSyncProvider ApplyChangeFailed event and SqlCeClientSyncProvider ApplyChangeFailed event, and ApplyChangeFailedEventArgs
For information about how to run sample code, see "Example Applications in the How to Topics" in Programming Common Client and Server Synchronization Tasks.
Understanding Database Provider Events
Sync Framework provides many events that expose both data and metadata that you can use during synchronization. For example, the SchemaCreatedEventArgs object provides access to the SyncSchema object for each table that was created in the client database, and also the connection and transaction over which the schema was created. This enables you to make schema changes through the API, within the same transaction as the client synchronization provider.
The time at which an event is raised is appropriate to its use, as you can see in the following examples:
The SchemaCreated event is raised after each table is created. This is useful if you have to make a schema change on one table before another table is created.
The DbServerSyncProvider ApplyingChanges event and SqlCeClientSyncProvider ApplyingChanges event is raised before changes are applied for each synchronization group. This enables you to view the metadata and set of changes for a group of related tables before those changes are applied.
The DbServerSyncProvider ApplyChangeFailed event and SqlCeClientSyncProvider ApplyChangeFailed event are raised after each failure to apply a row. This might occur because of an error or data conflict. These events enable you to respond to each error before processing continues. This could reduce the number of attempts at retrying failed changes.
Example
The example code in this topic shows you how to respond to Sync Services events by displaying synchronization progress to the screen, logging event-related data for applied and failed changes, and changing data during synchronization to enforce business logic. Instead of breaking this example into code examples, it is more useful to run the sample code, and to see what data is displayed and logged for each event by the EventLogger and SampleStatsAndProgress classes. However, before you run the sample code, we recommend that you look at the following code example.
Performing Business Logic During Synchronization
This example shows the control that you have over data during synchronization. It shows you how to access the set of changes before it is applied at the server by handling the server-side ApplyingChanges event. The example also shows you how you can introduce logic for the client-side event. In this case a column is updated. However, you could easily perform an inventory check, or any other business logic that an application requires, before changes are committed at the server or client. For examples of how you can do this when data conflicts occur, see How to: Handle Data Conflicts and Errors.
Complete Code Example
The following complete code example requires the Utility class that is available in Utility Class for Database Provider How-to Topics.