Reset Client Sync Data

[Lewis Stairs]

Hello,

In order to attempt to fix a small problem in our FM Go application, I would like to be able to reset the sync data on the Go Client so that MirrorSync effectively sees it as an initial sync and therefore res-syncs all necessary data. Is this possible? If so, please could you provide the steps that would need to be scripted in order to start the client file from scratch? 

As a small amount of background on the issue I am trying to fix, when the parameters change for the records to sync (ie a different set of records) sometimes, the sync process misses out a very important table, which requires the user to download a new copy of the FM Go file to then sync correctly. If anyone has any thoughts on this, that would be great. 

Thank you in advance

Lewis

[Jesse Barnum]

You should definitely not do this if you're using MirrorSync-managed keys (serial numbers).

If you're using UUIDs, it MIGHT work to do this as an initial sync, but I can't promise that it will work correctly. If you'd like to do it anyway, 1) make a backup copy of the server and client file, then 2) delete the record in the MirrorSync table where type=client. The next sync will run as if it were an initial sync. 

The best approach would be to simply get them a new offline file.

[Lewis Stairs]

Hi Jesse,

Thank you for replying so quickly, and sorry that I did not see it until now. 

We are not using MirrorSync managed keys, so I would like to try it out in a closely monitored environment. It does worry me though that you do not recommend it! The sync only runs one way - hub to spoke - so I would hope that might ease some of your concerns? If not, when you have the time, are you able to provide a brief explanation as to why it is a bad idea to reset the data on the users file as if it had just been downloaded fresh, please? Anything you could provide on this would be greatly appreciated.

Thank you for all your help

Lewis

[Jesse Barnum]

The initial sync process assumes that 1) the data on the offline copy is an exact match from the server, except for changes made since the database was downloaded. It also assumes that 2) the changes made since the database was downloaded would only be changed on one device (either the hub, or the spoke, but not both).

When you take an already synced database and trick MirrorSync into thinking that it's an initial sync, then assumption #1 is true but it might be inefficient because a lot will have changed since the date the database was copied from the server. Assumption #2 is not true at all, which may lead to record conflicts.

So my concern is that it may be very slow, and might lead to incorrect reports of record conflicts. However, the speed may be acceptable, and the conflict resolution may be harmless since the data will probably match on the hub and the spoke, so it might be fine.

[Lewis Stairs]

Thank you very much, Jesse.

I'll take all of that into account, do some testing and let our client decide. It is good to know the possible pitfalls so that we can understand why, should anything go awry. 

Thanks again,

Lewis