Working with Microsoft® Sync Framework

Micromine Geobank 23.0 utilises the Microsoft® Sync framework to synchronise data between a central Geobank system and a subsidiary system on a field device, with filtering to control subsidiary data. A number of risks are involved in the filtering of data in this manner and steps can be taken to mitigate them. The following table provides useful information on avoiding issues that may occur with filtering and the Microsoft® Sync framework.

RISK	MITIGATION
When data is change on the central system, the same change occurs in the subsidiary system. Because the whole row is synchronised, data on the subsidiary may be overwritten.	Carefully manage Site_Status so that once a row is entered into the filter to be synchronised, data is not changed. Site-lock, a trigger or security token enforcement could be configured.
Deleting an item in the filter on the central system causes the item to be deleted on the sub. If a row has no children on central, but already has children on the subsidiary, an error with be thrown on synchronisation.	Carefully manage Site_Status so that once a row is entered into the filter to be synchronised, data is not deleted. Site-lock, a trigger or security token enforcement could be configured.
A change to key field data on the central system does not cause the same key change on the subsidiary. The old key remains 'as is' in the tracking table and the new key is not added. This can be confusing to the user.	Do not change key values if Site_Status has created the potential for the data to have been taken by a logger. Instead, add a new row on the central system with a note for the logger.
Delete on the subsidiary causes that key to become ‘permanently’ irretrievable from central. This may be confusing, as the user may expect it to refresh/reappear on a subsequent synchronisation (e.g. if it becomes re-available for logging a few months later).	Do not delete keys from the subsidiary unless you are certain they do not need to be retrieved. Future versions of Geobank may include a step in the system ‘clean-up’ procedure to allow for keys to be ‘recycled’.
Insert on the subsidiary creates a row which is independent until the same key comes into the filter on central; at which point the row in the subsidiary is overwritten. Field Geologists can add a key manually (e.g. if it was not yet ready at central before they went offline) and then complete logs, which will cause some data to be overwritten on the next synchronisation.	Stick to the process as closely as possible. Avoid a mix of manual adds and adds from central. Always do the handover operation before the retrieve operation to avoid data ready for handover being unexpectedly changed.