ignotum

I am ok for now, I was able to disable one of the 2 plug-ins on the problematic machine. I'll wait for the full release. THANKS!

Was a fix ever released?

Explain this: A new table was added to a solution that has been syncing with no problems for a long time. This new table contains fields with data in non-Latin characters. Sync fails with a 106 error. Remove the table from the sync ("x" out their TOs in the client & Master) and sync works. Re-enable that table to sync without touching anything else and the sync still works. Ideas?

(thought I had new info.... maybe)

I have not tested this yet so I'll ask: Does this stop an iPad with the keyboard set to Chinese from entering in the field? What happens in that situation? I just tested on a Mac desktop in FMPA16 and with the language set to Russian I can type in a field set to have the method option set to Roman.

Is there any way for me to detect the keyboard language that is selected on the device? If not is there a way to know if a non Latin character is entered? (I'm researching unicode but have not found a clear way to :know" if a character is non-Latin) Mark

WAY old topic but I found that if I had records with missing ES_UUIDs I would get a 106 error. I can verify that in my situation the problem was data. I enabled PULL debug and saw ?ES for a table name. I cleaned up bad data on the Master file manually and the problem went away.

Or if FMI let us see the script name AND the ID when specifying we could reasonably take responsibility for the issue - and also: we should be able to change the ID (validating unique) if we need to match across >1 file.

The bug is that the external call is picking a script rather than returning "unknown" and failing. But running a different script data damage is possible. Hard to believe that internally FMI has chosen to use a simple serial number for ScriptIDs rather than a UUID/hash of some sort... not what most would call a "best practice".

(This has been reported to FMI with no response thus far.) Filemaker 16 FMPA & Server Mac client, PC server Scenario: I have a client's "MASTER" file HOSTED on an FMS at a hosting company. I have a copy of that "MASTER" file on a development FMS at my office. After that copy was made I added a script to both MASTER files. (wrote it on one, copy/paste to the other) I have a LOCAL file that calls that script in the MASTER file. In my LOCAL file I set up the External File Reference to the MASTER file on the hosted FMS. I set up the script in the LOCAL file to call the MASTER file script on the hosted FMS. All is well. I then change the External File Reference to the MASTER file on my development server. Now when I look at the script in the LOCAL file I would expect one of two things: the Perform Script step to the script on the MASTER file would either: 1. still be connected to the correct script or (more likely) 2. show <unknown> for the name of the script it is looking to call. BUT INSTEAD the call is linking to an entirely different script. It has a different script in the Perform script call - one that has nothing to do with the process. Clearly this is a dangerous bug. I can (probably) solve the issue for me in this one case by grabbing a copy of the client's MASTER file to my DEV server then relinking the external script call. At that point the call should "stick". BUT this is a potential data-damaging bug that could crop up in any similar client/development environment. Mark

Time. If I find the time... this stuff is embedded in our solution and I can't post that due to NDA etc.

Was this clear?

What Barbara and I did was this: //In the EasySync script "Push payload" //From the original script g //Given $temp_recs = Evaluate ( $dyn_esql ) //and $$max_push_segment_size //set to some value in the ES settings script $start = 1 $find = "</" //set a variable $string = Middle ( $temp_recs; $start ; $$max_push_segment_size) //set a variable $length //as seen in the attached "Parse Data" pdf //Then use that variable to figure out how much text to grab from the incoming string $segment_recs = Middle ( $temp_recs ; $start ; $length ) //then $start = $start+$length //See the attached Script.tiff for a screen capture of the script section above... Hope this is helpful. mark Parse data.pdf Script.tiff

How does mirrorsync handle the modification date/time stamp for record modification if users are all over the world with their computers set to local time? Mark

To follow up it LOOKS like a plug-in version issue! Lesson: check the simple things first... I'll be able to swap the plug in tonight, I'll report back after that... Thanks to Caleb for his help and support on this... and that you Ryan for posting here...