Switching Sync Methods Guided Recommendations

[Ocean West]

Currently on MS 3.v2 upgrade went fine copied script steps into the files currently using XML method for sync.

• do end users need a new clone and re-sync?  
• what happens to users who have the old v1 script?

Switching to JDBC will require the following True/False:

1. review the customization script for the logic used to filter records (this script is not used for JDBC)
2. config ms for JDBC
3. rework logic into an SQL fashion so sync will behave the same with regards restricting records to sync
4. copy script from updated config
5. paste script to database
    

• do end users need a new clone and re-sync?  
• what happens to users who have the old v1 script (still using xml)?

 

[Jesse Barnum]

Hi Stephen!

First of all, wait for 3.03 to come out (probably Monday, maybe Tuesday). I made some important JDBC fixes over the weekend. Sorry for the false start on 3.02.

Users with the 3.01 script will be fine to sync with 3.02, or 3.03. I've made some minor improvements to the deletion scanning that require the latest (3.03) script, but they're not important.

As you noted, with JDBC you will need to use the SQL qualifiers instead of the MirrorSync customization script.

However, when using JDBC, the MirrorSync script on the server is not actually used at all, so it's totally optional to re-paste the script steps (only needed if you decide to switch back to XML). You can switch back and forth between XML and JDBC on the server without distributing new offline files. The XML / JDBC setting is not used on the client, it's only between the MirrorSync server and the FileMaker Server.

[NateJames]

 

Quote

You can switch back and forth between XML and JDBC on the server without distributing new offline files. The XML / JDBC setting is not used on the client, it's only between the MirrorSync server and the FileMaker Server.

OK thats a very important point for everyone to remember, as its recommended in the wiki to try both sync setup to see what ever one works best for your solution....

So in theory, if I have this right, I could have an existing sync configuration called "sync-jdbc". I could duplicate the sync config with the MS tool, modify it and rename the new sync config, referencing the same server hosted file, set it up using xml, calling it "sync-xml".

          (at this point MS will make me new scripts to past in my file, appended with the new "sync-xml" name)

By doing that, it would be a fair test to see which performs better for my solution...and than I have my choice on the customization I want to use...

Is that a feasible test?

Edited October 4, 2016 by NateJames
added comments

[Jesse Barnum]

I haven't done that exact thing, but it sounds to me like that would be a valid test.