Jump to content

Developer keys versus Mirror Sync Managed


This topic is 1720 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Hello 360Works,

I am looking to refresh my current database into a new cleaner version. During this process I am looking to modify the primary keys so that I am not using user friendly serial numbers (example invoice ID's).

To do this requires some work on my end, and I have consulted the advanced topic section regarding Mirror Sync Managed vs Developer managed. I imagine that developer managed keys are faster than MirrorSync managed. Is there any data to support my assumptions? It would also seem that there maybe other reasons that you would want to use developer managed over MirrorSync managed, for instance I am thinking that using multiple sync configurations might benefit on this setup. Can you elaborate more on this as I have not had much success with multiple sync configurations and have not adapted to using this in my solution.

OR

Is there a possibility that there is going to be a new version of MirrorSync that will use internal ID's (field and record's) and I shouldn't invest to much time into doing this

(I am transitioning a file from FMSP 4.5 to FMSP 7)

Link to comment
Share on other sites

Hello,

Yes, developer-managed keys should perform better because it is not having to reference a SyncJoin to verify record-matching across the sync---it will only make changes based on the actual primary key values of the records. However, this performance difference may be negligible as compared to other factors like database size, network speed, server specs, etc.

The only other reasons developer-managed keys(assuming you're using UUIDs) are that UUIDs are less prone to duplications, and also, should you run into any sync data issues, the option to use our built-in Repair sync data feature is available only if the sync configuration employs developer-managed keys.

Having multiple sync configurations in your solution will not take away from the reliability of MirrorSync-managed v developer-managed keys beyond the reasons mentioned above. If you need to reset your sync data for any reason, all of the sync configurations associated with the same file located at the same address will be affected.

MirrorSync already keeps an internal db associating matching records across the sync. If you do not configure the settings in your database to ensure record key uniqueness across multiple instances of the database(e.g. employing UUIDs), then you should select MirrorSync-managed keys in your sync configuration.

Link to comment
Share on other sites

This topic is 1720 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.