Troubleshooting
Debugging
If you've hosted your files on FileMaker Server, you'll want to run the script "Toggle Perform Script On Server Off For This Session" from your mobile file before you start following sync scripts in the script debugger.
Without that run, some of the scripts run via Perform Script on Server and you can't follow those in the script debugger =). With that script run all these scripts will execute in FileMaker Pro client so you can follow them.
More tips for using the Script Debugger with GoZync here: Debugging Tips.
General Gotchas
Nothing works, Can't Connect, or modified records not syncing down to mobile.
If the configuration checks out with green check marks but you get NO sync action, try clicking the "reset" button in the lower left of GoZync mobile: it may be just that you don't have changes since your last sync.
If that doesn't help, or you can't connect, it is likely your file references (External Data Sources): more on checking those here.
If you're using the trial version of FileMaker Server, remember that it only allows one connection at a time. So if your desktop is connected to the trial of Server you'll need to close that connection before your iPad can sync.
You'll also want to make sure that the mobile users are authenticated into your hosted solution with a privilege set that lets them edit records. If all that sounds like stuff you've never heard of, this likely isn't your problem. This only comes up when folks have more elaborate security set ups.
Another security gotcha could be that you've enabled File Access Protection. Learn about why this doesn't make sense for synced systems--and how to turn it off--towards the end of the page here.
Syncing Every Record instead of Just Those Changed Since the Last Sync.
Make sure you've made the version 5.032 change described here. If that's in place see if the "Filter Records To Pull" script in your hosted file is set to disregard the last sync time (there is an option for this, usually commented out, for each table).
It could also be that GoZync isn't getting the last sync time properly. Run the script debugger into the script "Get IDS Needed For Sync PSOS" and you should see the last sync time appear as a local variable in line 13 (the second SetVariable) line: if it looks good there but is turned into a "?' a few lines late at line 22, then GoZyncMobile and your hosted file have different internal date formats. Follow the instructions here for cloning GoZyncMobile and you should be all set: Date Formats. Or, make the date and time change in version 5.09 of GoZync. Instructions are here: Version History.
If this is happening only to a specific table, Make sure the sync Layout in your hosted file is based on the correct TO. The layout name and the Base TO name should be the same and should begin with "gzh_". If they don't, GoZync will not be able to find the records that have changed since the last sync
All Records are Deleted from Mobile file when syncing.
If all records are being deleted from the mobile file on a sync, it may be a problem with IDs or the gz_id_ListOf field. GoZync uses the "ListOF" summary field to get the list of IDs in the found set to sync. If that gz_id_ListOf field is incorrect, no IDs are returned for syncing, causing all records to get deleted in the mobile file.
Push works but pull doesn't unless you hit "reset".
If you're outside the United States you may have a date format conflict in GoZyncMobile preventing it from properly finding records modified since the last sync. This is easily fixed here: date formats & cloning GoZyncMobile.
Some fields not syncing.
The most common cause of unexpected sync behavior is that you're not syncing the layout you think you are. Remember, GoZync syncs the fields on your sync layout so visit the configuration tab in GoZyncHosted and make sure the layouts you've specified there are the ones you want to use.
Another cause could be that the field's name begins with a numeral or period, has the same name as a FileMaker function, or contains the word "or", "and" or "not", or a symbol that's being interpreted as an operator.
This could be because you haven't actually triggered a modification in the parent record.
It could also be that your related table uses a relationship not based on the primary key of the parent's record table. Related tables to be synced must be related to the primary key of their parent record. More complex relationships should be synced as their own tables.
Finally, you may have specified the wrong field or table when filling out the "required" column on the configuration tab of GoZyncHosted, so double check that.
One of my tables has a generic sync error, or I'm seeing duplicate records
Make sure your primary key field (the UUID field) isn't empty in any existing records. This can happen if there are already records in the table when the UUID field is created. Missing UUIDs can cause sync issues that are hard to spot. The solution is to Find those records where the UUID field is empty and use FileMaker’s “Replace Field Contents” command with the Get(UUID) function to give that field a unique value in those records.
Blank records seem to be added in one of my files with each sync
If you've set up custom field mapping in the "Custom Field Mapping: Transformation and Hooks" script in GoZyncMobile, make sure that any Set Field steps in this script are mapped to the appropriate fields. There may be a Set Field step referencing a table occurrence other than the gzm/gzh pair that you've identified in the If or Else If statement. For more info on this, see this forum post.
File is Locked or In Use when pulling down a new version
FileMaker Go13 takes a bit longer to close files than Go12 did so you may need to increase the time GoZync waits for your file to close before replacing it. This can be exacerbated by large files or slower (older) devices.
Instructions for changing this are here. If the 1 second delay mentioned there doesn't work, add 4 seconds and see if that gets it. Then back down to 3 or 2 seconds to find the time that works for your file.
If you are running an older version of iOS, try updating your mobile device. In some cases, this file locked issue has been resolved after updating to the current iOS version.
What do error codes in the GoZync logs really mean?
Any errors encountered in the sync will be reported in the zync logs tabs in GoZyncMobile and GoZyncHosted.
Many of the errors will be self explanatory, but the guide below may help.
• 101 Record is missing. This is about the table occurrence, not the field.
Most likely reason for this is that you don't have "Allow creation of records..." set to "on" for this table in its relationship with GoZync in the graph of GoZyncMobile.
Turn "Allow creation..." on for the table occurrence mentioned in the error and then try again.
• 102 Field Missing. There are only a few reasons why you'd see a 102 error.
You've sent a field that doesn't exist in the destination. Remove the field from the sync layout on the source side (the sending side). Note that fields don't have to be on the sync layout in order to be received; fields only need to be there to be sent.
The field exists but has a different name in the destination. See Custom Field Mapping to transform the field name.
You've created a transformation (a custom field mapping) but your field is repeating and you haven't created a field mapping for each repetition.
If these don't apply, see the section "Other Sync Errors" under Troubleshooting.
• 106 Table is Missing
There is a mismatch between the table occurrence names on the mobile and hosted side of the relationship graph in GoZyncMobile. Even if your actual tables are named something different in the mobile and hosted files, the *occurrences* for those tables in GoZyncMobile's relationship graph need to have the same name (outside of the "gzm_" or "gzh_" prefixes).
You may connected the TO to GoZync on the destination side of the GoZyncMobile graph.
One other thing, that can be hard to spot at first, is that the relationship graph in GoZyncMobile *look* good, but the table occurrences--while named correctly--are either representing the wrong tables or are both pointing at the same file (ie gzm_Contacts and gzh_Contacts are both pointing to the contacts table in your hosted file, for example).
• 200 Record access is denied.
In this case, access to the records being synced is not permitted for the account being used. Permission must be granted in the mobile and hosted file for each field that will be synced.
• 301 Record is in use by another user. Commonly called "record lock".
This is exactly what it sounds like: it's not a configuration error.
FileMaker couldn't edit the record (or one of the related records for that entity) because another user was editing it. Feel free to try and sync the record later when the original user has stopped editing it.
• 500-511 Validation Errors.
These will occur when the data coming in fails to meet the validation criteria set up on one of your fields.
You can turn off the validation or change it from "always" to "only during data entry" which will stop it from firing during scripted set fields like those used in GoZync.
You could include a flag-field condition in the validation calculation, then set that flag at the start of the Zync routine, and clear it when it's done.
You could modify the "Commit Records/Requests" step in the "Zengine ( IDsToSync )" script to "Skip data entry validation".
Or you could remove the field validation altogether and instead write a script to do it, then run that script on the server.
Can't reach the license server
This error will show when trying to activate a new license and your computer can't reach the license server.
Make sure you can connect to http://seedcode.info
If you're running FileMaker 16, make sure you've upgraded to GoZync 5.12 or later. Update instructions can be found here here.
License Violation Detected
Pretty rare, but if you're seeing this message it can be caused by one of four things:
You're syncing more than your license allows.
You're trying to call some of the GoZync sub scripts without including our license file (unlikely, unless you're trying to bypass the license).
Other Sync Errors
"We couldn't set the field, "gzm_YourTable::"
If you see "We couldn't set the field, "gzm_YourTable::" Notice that there is no field name, only the TO name. This means that a layout has become corrupted. The solution is to delete both the gzh_ and gzm_ layouts for that table in GZM, and then create new layouts from scratch with the same names and with the same fields on them. Don't copy/paste anything, so as to avoid retaining any of the corruption.
"Hosted files aren't open - Unfortunately we couldn't establish a connection to one or more of the Hosted files. Closing GoZyncMobile"
This error can happen either because your hosted file is not available at the location specified, or you have a gzm_ layout without a matching gzh_ layout in GoZyncMobile. Verify your external data sources and that each gzm_ layout has a matching gzh_ layout with the same suffix.
Authentication Errors in Server Logs
This isn't actually an error: FileMaker Server is just a little too verbose in its logging, and while many people have asked FileMaker to change this, it's been around for a while. What's happening is that the user has other files in the set up that open with "Admin" as the account name. When one of those files calls a script in GoZyncHosted, FileMaker tries to open GoZyncHosted using the same credentials--tries to pass that authentication into the related files. This is a great feature of FileMaker, but in our case, GoZyncHosted doesn't have an Admin account. So, the attempt fails--and FileMaker Server logs the "error" even though the user never sees it. FileMaker then tries the "On Opening" account setup in GoZyncHosted hosted and the solution opens right up. You'll see the same error in FileMaker Server any time two files in solution don't share the logged in account or password. It's not an error and we all wish it wouldn't show up in the log.
FIleMaker "Next": Changes Required
FileMaker introduced a new extended privilege in Next that permits the FMP URL protocol to function. The first time you open GoZync, DayBack, or any webviewer-heavy solution in next without this privilege enabled, you'll see this error:
GoZync uses the FMP URL to re-open files after downloading a new version.
The fix is simply to enable the new privilege in GoZyncMobile and your Mobile File. Here's how.
- 1. Select File / Manage / Security from the FileMaker menus.2. Click on the "Extended Privileges Tab", then double-click the "fmurlscript" keyword.3. Check "on" for any privilege sets you wish to be able to use DayBack.4. That's it!
Why did FileMaker make this change? They believed that malicious users who knew your script names could trigger them from URLs even if you didn't provide buttons for those scripts. But users would still need to be logged into FMP with sufficient permission to run the script: the FMP URL doesn't bypass FileMaker security in any way.
Updating the mobile file freezes / won't complete
iOS recently was updated so that the custom function to detect whether FileMaker Go was running under the Native App or SDK no longer functions.
Since we're no longer able to detect this, GoZync versions 5.08-5.12 will not be able to update the mobile file without making the following change:
The Fix
The fix requires updating the IsNativeApp custom function. Modifying custom functions requires FileMaker Pro Advanced. If you don't have access to Advanced, feel free to reach out and we'll be glad to make the change for you.
When using GoZync as normal, replace the entire calculation of the IsNativeApp custom function to return 0. Nothing else, just 0
If you are running the SDK to test GoZync, you'll need to update the Custom Function to return 1.
