Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


ignotum last won the day on October 4 2017

ignotum had the most liked content!

Community Reputation

2 Neutral

About ignotum

  • Rank
    FileMaker R Us

Profile Information

  • Title
    President and...
  • Gender
  • Location
    metro NYC

FileMaker Experience

  • Skill Level
  • FM Application
    16 Advanced

Platform Environment

  • OS Version
    Mac & Windows

FileMaker Partner

  • Membership
    FileMaker TechNet
    FileMaker Business Alliance

Recent Profile Visitors

2,470 profile views
  1. 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!
  2. 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?
  3. (thought I had new info.... maybe)
  4. 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.
  5. 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
  6. 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.
  7. 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.
  8. 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".
  9. (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
  10. Time. If I find the time... this stuff is embedded in our solution and I can't post that due to NDA etc.
  11. 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
  12. 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
  13. 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...
  • Create New...

Important Information

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