ignotum

Does a record "exist" for MirrorSync BEFORE it is committed in FileMaker? MirrorSync is reporting errors for missing primary keys. When I look at the data the keys are there. Is there a period of time during record creation, maybe of child/related records from the parent and/or before the new record is committed, when MirrorSync might grab a record that is incomplete?

I read the below... we are syncing tables in a file on FMS with SQL Server tables. We have ALL fields ont he sync layout, including all of the usual auto enter account, user, date and time fields. We have not experienced problems. Are we OK because we are syncing a FM Server file with SQL (that will be modified by web users once we get this all up and running) andnot syncing FM users to FMS? mark Can I have more than one modified auto enter field on my sync layout? No, MirrorSync only allows for one "modified" auto-enter field on the layout, the modif

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

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 muc