Troubleshooting
GoZync5.Troubleshooting History
Hide minor edits - Show changes to output
January 22, 2018, at 06:46 PM
by - Fixed ghz to gzh typo
January 22, 2018, at 06:46 PM
by - Fixed ghz to gzh typo
Changed line 99 from:
-> 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 ghz_ 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.
to:
-> 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.
October 31, 2017, at 12:27 AM
by - Added section for hosted files aren't open error when missing gzh layout
Added lines 97-98:
'''"We couldn't set the field, "gzm_YourTable::"'''
Added lines 100-103:
'''"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.
September 27, 2017, at 04:31 PM
by - Added table specific sync all records section
Added lines 29-30:
-> 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
July 20, 2017, at 08:57 PM
by - Updated license server section
Changed line 77 from:
->Make sure you can connect to seedcode.info
to:
->Make sure you can connect to [[http://seedcode.info]]
July 20, 2017, at 08:56 PM
by - Updated license server section
Changed lines 77-79 from:
->Make sure you can connect to seedcode.com
->If you're running FileMaker 16, make sure you've upgraded to GoZync 5.12 or later by following the instructions %newwin% [[http://www.seedcode.com/support/viewtopic.php?f=38&t=4373 | here]].
to:
->Make sure you can connect to 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 %newwin% [[http://www.seedcode.com/support/viewtopic.php?f=38&t=4373 | here]].
->If you're running FileMaker 16, make sure you've upgraded to GoZync 5.12 or later. Update instructions can be found here %newwin% [[http://www.seedcode.com/support/viewtopic.php?f=38&t=4373 | here]].
July 20, 2017, at 08:51 PM
by - Added #LicenseServer section
Added lines 71-80:
[[#LicenseServer]]
!! 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 seedcode.com
->If you're running FileMaker 16, make sure you've upgraded to GoZync 5.12 or later by following the instructions %newwin% [[http://www.seedcode.com/support/viewtopic.php?f=38&t=4373 | here]].
Changed lines 83-84 from:
-> 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 that layout in GZM, then create a new layout from scratch with that same name and with the same fields on it. Don't copy/paste anything, so as to avoid retaining any of the corruption.
to:
-> 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 ghz_ 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.
Deleted line 111:
May 18, 2017, at 12:17 AM
by - Added Update Freezing/SDK section
Added lines 108-113:
[[#UpdateFreezes]]
!! Updating the mobile file freezes / won't complete
(:include SDK:)
Changed lines 89-91 from:
!!FIleMaker "next": Changes Required
FileMaker introduced a new extended privilege inFM16 that permits the FMP URL protocol to function. The first time you open GoZync, DayBack, or any webviewer-heavy solution in FM16 without this privilege enabled, you'll see this error:
FileMaker introduced a new extended privilege in
to:
!!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:
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:
March 23, 2017, at 09:47 PM
by - added #RelatedRecordsNotSyncing
Added line 45:
[[#RelatedRecordsNotSyncing]]
Changed lines 85-105 from:
-> 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.
to:
-> 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 FM16 that permits the FMP URL protocol to function. The first time you open GoZync, DayBack, or any webviewer-heavy solution in FM16 without this privilege enabled, you'll see this error:
%center% %newwin width=440px% [[http://www.seedcode.com/rootimages/stikipad/dayback/urlerror1-2.png | http://www.seedcode.com/rootimages/stikipad/dayback/urlerror1-2.png]]
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.
!!FIleMaker "next": Changes Required
FileMaker introduced a new extended privilege in FM16 that permits the FMP URL protocol to function. The first time you open GoZync, DayBack, or any webviewer-heavy solution in FM16 without this privilege enabled, you'll see this error:
%center% %newwin width=440px% [[http://www.seedcode.com/rootimages/stikipad/dayback/urlerror1-2.png | http://www.seedcode.com/rootimages/stikipad/dayback/urlerror1-2.png]]
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.
March 20, 2017, at 08:29 PM
by - Fixed link to version history
Changed line 28 from:
-> 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 Hstory]].
to:
-> 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]].
Changed line 27 from:
-> 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]]
to:
-> 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 Hstory]].
February 13, 2017, at 11:03 PM
by - Updated General Gotchas summary
Changed line 11 from:
'''Nothing works or Can't Connect.'''
to:
'''Nothing works, Can't Connect, or modified records not syncing down to mobile.'''
January 31, 2017, at 06:54 PM
by - Added #MobileRecordsDeleted
Changed line 29 from:
to:
[[#MobileRecordsDeleted]]
May 19, 2016, at 10:28 PM
by - Note about updating iOS for File Locked issue
Added lines 65-66:
-> 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.
April 21, 2016, at 12:32 AM
by - Added section about blank records being added
Added lines 55-58:
'''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 [[http://www.seedcode.com/support/viewtopic.php?f=38&t=4284 | forum post]].
Changed line 27 from:
-> 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:
to:
-> 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]]
Added lines 26-28:
-> 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:
February 10, 2016, at 02:56 PM
by - Added note about all records being deleted from mobile file.
Added lines 26-29:
'''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.
Changed lines 66-70 from:
-> 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 that layout in GZM, then create a new layout from scratch with that same name and with the same fields on it. Don't copy/paste anything, so as to avoid retaining any of the corruption.
to:
-> 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 that layout in GZM, then create a new layout from scratch with that same name and with the same fields on it. Don't copy/paste anything, so as to avoid retaining any of the corruption.
!! 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.
!! 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.
Changed line 66 from:
to:
-> 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 that layout in GZM, then create a new layout from scratch with that same name and with the same fields on it. Don't copy/paste anything, so as to avoid retaining any of the corruption.
Added lines 34-35:
-> 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.
Deleted lines 60-61:
-> Or one of your layouts is unable to be read by FileMaker (this is a FMP bug short of corruption). For this one, sync each layout individually from GoZyncMobile and if you find one that gives the license error, delete that sync layout in GoZyncMobile and recreate it.
Changed lines 62-66 from:
-> Or one of your layouts is unable to be read by FileMaker (this is a FMP bug short of corruption). For this one, sync each layout individually from GoZyncMobile and if you find one that gives the license error, delete that sync layout in GoZyncMobile and recreate it.
to:
-> Or one of your layouts is unable to be read by FileMaker (this is a FMP bug short of corruption). For this one, sync each layout individually from GoZyncMobile and if you find one that gives the license error, delete that sync layout in GoZyncMobile and recreate it.
!! Other Sync Errors
Occasionally a layout will become corrupted, and often the error message in the log will be something like "We couldn't set the field, "gzm_YourTable::" Notice that there is no field name, only the TO name. The solution is to delete that layout in GZM, then create a new layout from scratch with that same name and with the same fields on it. Don't copy/paste anything, so as to avoid retaining any of the corruption.
!! Other Sync Errors
Occasionally a layout will become corrupted, and often the error message in the log will be something like "We couldn't set the field, "gzm_YourTable::" Notice that there is no field name, only the TO name. The solution is to delete that layout in GZM, then create a new layout from scratch with that same name and with the same fields on it. Don't copy/paste anything, so as to avoid retaining any of the corruption.
Added lines 26-29:
'''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: [[DateFormats | date formats & cloning GoZyncMobile]].
Added lines 22-25:
'''Syncing Every Record instead of Just Those Changed Since the Last Sync.'''
-> Make sure you've made the [[Version History | version 5.032]] change described [[http://www.seedcode.com/support/viewtopic.php?f=38&t=4086 | 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).
Changed lines 15-17 from:
-> If that doesn't help, or you can't connect, it is likely your file references (External Data Sources): more on checking those [[ExternalDataSources | here]].
to:
-> If that doesn't help, or you can't connect, it is likely your file references (External Data Sources): more on checking those [[ExternalDataSources | 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.
-> 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.
Changed lines 33-35 from:
'''One of my tables has a generic sync error'
Check to make sure you have values in the UUID field this table is pulling from. Missing UUIDs can cause sync issues that are hard to spot
to:
'''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.
-> 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.
Changed lines 39-41 from:
-> 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. Instructions for changing this are [[http://www.seedcode.com/support/viewtopic.php?f=38&t=4017 | 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.
to:
-> 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 [[http://www.seedcode.com/support/viewtopic.php?f=38&t=4017 | 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.
-> Instructions for changing this are [[http://www.seedcode.com/support/viewtopic.php?f=38&t=4017 | 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.
Added lines 18-19:
-> 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 [[security | here]].
Changed line 37 from:
-> 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. Instructions for changing this are [[http://www.seedcode.com/support/viewtopic.php?f=38&t=4017 | 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.
to:
-> 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. Instructions for changing this are [[http://www.seedcode.com/support/viewtopic.php?f=38&t=4017 | 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.
Added lines 35-37:
'''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. Instructions for changing this are [[http://www.seedcode.com/support/viewtopic.php?f=38&t=4017 | ]] 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.
-> 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. Instructions for changing this are [[http://www.seedcode.com/support/viewtopic.php?f=38&t=4017 | ]] 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.
Added lines 6-7:
-> More tips for using the Script Debugger with GoZync here: [[debugging | Debugging Tips]].
Added lines 1-6:
!! 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.
-> 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.
Changed line 25 from:
-> Check to make sure you have values in the UUID field this table is pulling from.
to:
-> Check to make sure you have values in the UUID field this table is pulling from. Missing UUIDs can cause sync issues that are hard to spot
Added lines 22-25:
'''One of my tables has a generic sync error'''
-> Check to make sure you have values in the UUID field this table is pulling from.
Changed lines 3-4 from:
'''Nothing works.'''
to:
'''Nothing works or Can't Connect.'''
Changed line 7 from:
-> If that doesn't help it is likely your file references (External Data Sources): more on checking those [[ExternalDataSources | here]].
to:
-> If that doesn't help, or you can't connect, it is likely your file references (External Data Sources): more on checking those [[ExternalDataSources | here]].
Changed lines 27-28 from:
Pretty rare, but if you're seeing this message it can be caused by one of three things:
to:
Pretty rare, but if you're seeing this message it can be caused by one of four things:
Changed lines 33-35 from:
-> Some of your field, layout, or table occurrence names include prohibited characters (!/~;&# etc) This is the most likely reason.
-> Orof your layouts is corrupt. For this one, sync each layout individually from GoZyncMobile and if you find one that gives the license error delete, that sync layout in your hosted and mobile file and recreate it. (These are the layouts in YOUR files, not on GoZynHosted, or GoZyncMobile.)
-> Or
to:
-> Or one of your layouts is unable to be read by FileMaker (this is a FMP bug short of corruption). For this one, sync each layout individually from GoZyncMobile and if you find one that gives the license error, delete that sync layout in GoZyncMobile and recreate it.
Deleted lines 10-11:
Changed lines 19-20 from:
-> 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 layouts.
to:
-> 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.
Changed lines 9-10 from:
-> You'll also want to make sure that the mobile users are authenticated into your hosted solution (via GoZyncHosted) 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.
to:
-> 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.
Deleted lines 24-29:
-> The sync layouts in your files can not have script triggers on them.
-> Visit the integration again in GoZyncHosted and click through the tabs for each table: tabs like "Field and Scripts" will run checks to make sure you don't have bad field names.
Changed lines 19-24 from:
-> This is either because the related fields aren't on your sync layout, or that you haven't actually [[TriggeringRecordMods | triggered a modification in the parent record]].
-> It could also be thatthe portals on your sync layout use a relationship ''not'' based on the primary key of the layout's table. Portal data to be synced must be related to the primary key of the table the portal is on. More complex relationships should be synced as their own layouts.
-> Finally, we've seen a few cases where the relationship used if your solution is based on fields X and Y where the graph you wired up in GoZyncMobile uses a field than X for the primary key in your table. Double check that what your solution uses as the primary key for a relationship is the same field you use as a primary key in the graphs of GoZyncMobile and GoZyncHosted.
-> It could also be that
-> Finally, we've seen a few cases where
to:
-> This could be because you haven't actually [[TriggeringRecordMods | 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 layouts.
-> 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.
-> 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 layouts.
-> 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.
Changed lines 31-32 from:
(:incude ErrorCodes:)
to:
(:include ErrorCodes:)
Changed lines 15-20 from:
-> 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 Integration in GoZyncHosted and make sure the layouts you've specified there are the ones you want to use.
-> Want to look closer? Turn off Field Level Merge in [[Zync Options]] and perform a sync for the table in question. Now visit the InBox in GoZyncHosted and export the last package: you'll see the fields being synced at the beginning of the package. If the fields you want to sync aren't there, they aren't on your sync layout in your mobile file.
-> Remember, you'll only see a package in InBox if you push or round-trip, to see pull packages, look at the Zync Logs tab in GoZyncMobile for the last package processed: that will show you the fields on your hosted zync layout.
-> Want to look closer? Turn off Field Level Merge in [[Zync Options]] and perform a sync for the table in question. Now visit the InBox in GoZyncHosted and export the last package: you'll see the fields being synced at the beginning of the package. If the fields you want to sync aren't there, they aren't on your sync layout in your mobile file.
-> Remember, you'll only see a package in InBox if you push or round-trip, to see pull packages, look at the Zync Logs tab in GoZyncMobile for the last package processed: that will show you the fields on your hosted zync layout
to:
-> 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.
Changed lines 5-8 from:
-> The most common issue when setting up as sync is that records appear not to sync but are simply waiting in the GoZyncHosted InBox to be processed. This could be because of a field mapping error, or simply because you only "pushed" and didn't do a round trip. You can learn more about how to automate inbox processing here: [[inbox processing]].
-> If the integration 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 the integration
to:
-> 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.
Deleted lines 22-23:
Deleted lines 0-3:
For errors processing the inbox in GoZyncHosted, see [[processing errors]].
Changed lines 13-14 from:
-> If that doesn't help it is likely your file references (Data Sources): more on checking those [[ExternalDataSources | here]].
to:
-> If that doesn't help it is likely your file references (External Data Sources): more on checking those [[ExternalDataSources | here]].
Deleted line 4:
Added lines 9-10:
-> The most common issue when setting up as sync is that records appear not to sync but are simply waiting in the GoZyncHosted InBox to be processed. This could be because of a field mapping error, or simply because you only "pushed" and didn't do a round trip. You can learn more about how to automate inbox processing here: [[inbox processing]].
Changed lines 5-16 from:
Pretty rare, but if you're seeing this message it can be caused by one of three 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).
-> Some of your field, layout, or table occurrence names include prohibited characters (!/~;&# etc) This is the most likely reason.
-> Or one of your layouts is corrupt. For this one, sync each layout individually from GoZyncMobile and if you find one that gives the license error delete, that sync layout in your hosted and mobile file and recreate it. (These are the layouts in YOUR files, not on GoZynHosted, or GoZyncMobile.)
to:
Changed lines 40-53 from:
-> Visit the integration again in GoZyncHosted and click through the tabs for each table: tabs like "Field and Scripts" will run checks to make sure you don't have bad field names.
to:
-> Visit the integration again in GoZyncHosted and click through the tabs for each table: tabs like "Field and Scripts" will run checks to make sure you don't have bad field names.
!! License Violation Detected
Pretty rare, but if you're seeing this message it can be caused by one of three 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).
-> Some of your field, layout, or table occurrence names include prohibited characters (!/~;&# etc) This is the most likely reason.
-> Or one of your layouts is corrupt. For this one, sync each layout individually from GoZyncMobile and if you find one that gives the license error delete, that sync layout in your hosted and mobile file and recreate it. (These are the layouts in YOUR files, not on GoZynHosted, or GoZyncMobile.)
!! License Violation Detected
Pretty rare, but if you're seeing this message it can be caused by one of three 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).
-> Some of your field, layout, or table occurrence names include prohibited characters (!/~;&# etc) This is the most likely reason.
-> Or one of your layouts is corrupt. For this one, sync each layout individually from GoZyncMobile and if you find one that gives the license error delete, that sync layout in your hosted and mobile file and recreate it. (These are the layouts in YOUR files, not on GoZynHosted, or GoZyncMobile.)
Changed lines 13-14 from:
-> Some of your field, layout, or table occurrence names include prohibited characters (!~;&# etc) This is the most likely reason.
to:
-> Some of your field, layout, or table occurrence names include prohibited characters (!/~;&# etc) This is the most likely reason.
Added lines 37-38:
-> For more on processing the inbox in GoZyncHosted, see [[processing errors]].
Added lines 43-44:
-> Finally, we've seen a few cases where the relationship used if your solution is based on fields X and Y where the graph you wired up in GoZyncMobile uses a field than X for the primary key in your table. Double check that what your solution uses as the primary key for a relationship is the same field you use as a primary key in the graphs of GoZyncMobile and GoZyncHosted.
Added lines 9-10:
-> You're syncing more than your license allows.
Added lines 25-26:
-> If you're not seeing records pushed up from Mobile to Hosted, the records could be ending up in GoZyncHosted's inbox and simply have processing errors (field name mismatch, etc.) check the GoZycHosted inbox to see if they are there.
Changed lines 31-34 from:
-> Want to look closer? Turn of Field Level Merge in [[Zync Options]] and perform a sync for the table in question. Now visit the InBox in GoZyncHosted and export the last package: you'll see the fields being synced at the beginning of the package. If the fields you want to sync aren't there, they aren't on your sync layout in your mobile file.
-> Remember, you'll only see a package in InBox if youpus or round-trip, to see pull packages, look at the Zync Logs tab in GoZyncMobile for the last package processed: that will show you the fields on your hosted zync layout.
-> Remember, you'll only see a package in InBox if you
to:
-> Want to look closer? Turn off Field Level Merge in [[Zync Options]] and perform a sync for the table in question. Now visit the InBox in GoZyncHosted and export the last package: you'll see the fields being synced at the beginning of the package. If the fields you want to sync aren't there, they aren't on your sync layout in your mobile file.
-> Remember, you'll only see a package in InBox if you push or round-trip, to see pull packages, look at the Zync Logs tab in GoZyncMobile for the last package processed: that will show you the fields on your hosted zync layout.
-> Remember, you'll only see a package in InBox if you push or round-trip, to see pull packages, look at the Zync Logs tab in GoZyncMobile for the last package processed: that will show you the fields on your hosted zync layout.
Changed lines 43-44 from:
-> The sync layouts in your file can not have script triggers on them.
to:
-> The sync layouts in your files can not have script triggers on them.
Changed lines 9-10 from:
-> You're trying to call some of the GoZync sub scripts without including our license file (unlikely).
to:
-> 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).
Changed lines 7-8 from:
to:
Pretty rare, but if you're seeing this message it can be caused by one of three things:
Changed lines 7-14 from:
-
-
to:
A pretty rare error, this can be caused by one of three things:
-> You're trying to call some of the GoZync sub scripts without including our license file (unlikely).
-> Some of your field, layout, or table occurrence names include prohibited characters (!~;&# etc) This is the most likely reason.
-> Or one of your layouts is corrupt. For this one, sync each layout individually from GoZyncMobile and if you find one that gives the license error delete, that sync layout in your hosted and mobile file and recreate it. (These are the layouts in YOUR files, not on GoZynHosted, or GoZyncMobile.)
-> You're trying to call some of the GoZync sub scripts without including our license file (unlikely).
-> Some of your field, layout, or table occurrence names include prohibited characters (!~;&# etc) This is the most likely reason.
-> Or one of your layouts is corrupt. For this one, sync each layout individually from GoZyncMobile and if you find one that gives the license error delete, that sync layout in your hosted and mobile file and recreate it. (These are the layouts in YOUR files, not on GoZynHosted, or GoZyncMobile.)
Added lines 5-14:
!! License Violation Detected
-> A pretty rare error, this can be caused by one of three things:
--> You're trying to call some of the GoZync sub scripts without including our license file (unlikely).
--> Some of your field, layout, or table occurrence names include prohibited characters (!~;&# etc) This is the most likely reason.
--> Or one of your layouts is corrupt. For this one, sync each layout individually from GoZyncMobile and if you find one that gives the license error delete, that sync layout in your hosted and mobile file and recreate it. (These are the layouts in YOUR files, not on GoZynHosted, or GoZyncMobile.)
-> A pretty rare error, this can be caused by one of three things:
--> You're trying to call some of the GoZync sub scripts without including our license file (unlikely).
--> Some of your field, layout, or table occurrence names include prohibited characters (!~;&# etc) This is the most likely reason.
--> Or one of your layouts is corrupt. For this one, sync each layout individually from GoZyncMobile and if you find one that gives the license error delete, that sync layout in your hosted and mobile file and recreate it. (These are the layouts in YOUR files, not on GoZynHosted, or GoZyncMobile.)
Added lines 13-14:
-> You'll also want to make sure that the mobile users are authenticated into your hosted solution (via GoZyncHosted) 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.
Changed lines 23-31 from:
-> This is either because the related fields aren't on your sync layout, or that you haven't actually [[TriggeringRecordMods | triggered a modification in the parent record]].
to:
-> This is either because the related fields aren't on your sync layout, or that you haven't actually [[TriggeringRecordMods | triggered a modification in the parent record]].
-> It could also be that the portals on your sync layout use a relationship ''not'' based on the primary key of the layout's table. Portal data to be synced must be related to the primary key of the table the portal is on. More complex relationships should be synced as their own layouts.
'''Other things to check...'''
-> The sync layouts in your file can not have script triggers on them.
-> Visit the integration again in GoZyncHosted and click through the tabs for each table: tabs like "Field and Scripts" will run checks to make sure you don't have bad field names.
-> It could also be that the portals on your sync layout use a relationship ''not'' based on the primary key of the layout's table. Portal data to be synced must be related to the primary key of the table the portal is on. More complex relationships should be synced as their own layouts.
'''Other things to check...'''
-> The sync layouts in your file can not have script triggers on them.
-> Visit the integration again in GoZyncHosted and click through the tabs for each table: tabs like "Field and Scripts" will run checks to make sure you don't have bad field names.
Changed lines 9-10 from:
-> If the integration 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.
to:
-> If the integration 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.
Changed lines 7-23 from:
to:
'''Nothing works.'''
-> If the integration 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 it is likely your file references (Data Sources): more on checking those [[ExternalDataSources | here]].
'''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 Integration in GoZyncHosted and make sure the layouts you've specified there are the ones you want to use.
-> Want to look closer? Turn of Field Level Merge in [[Zync Options]] and perform a sync for the table in question. Now visit the InBox in GoZyncHosted and export the last package: you'll see the fields being synced at the beginning of the package. If the fields you want to sync aren't there, they aren't on your sync layout in your mobile file.
-> Remember, you'll only see a package in InBox if you pus or round-trip, to see pull packages, look at the Zync Logs tab in GoZyncMobile for the last package processed: that will show you the fields on your hosted zync layout.
'''Related records not syncing.'''
-> This is either because the related fields aren't on your sync layout, or that you haven't actually [[TriggeringRecordMods | triggered a modification in the parent record]].
-> If the integration 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 it is likely your file references (Data Sources): more on checking those [[ExternalDataSources | here]].
'''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 Integration in GoZyncHosted and make sure the layouts you've specified there are the ones you want to use.
-> Want to look closer? Turn of Field Level Merge in [[Zync Options]] and perform a sync for the table in question. Now visit the InBox in GoZyncHosted and export the last package: you'll see the fields being synced at the beginning of the package. If the fields you want to sync aren't there, they aren't on your sync layout in your mobile file.
-> Remember, you'll only see a package in InBox if you pus or round-trip, to see pull packages, look at the Zync Logs tab in GoZyncMobile for the last package processed: that will show you the fields on your hosted zync layout.
'''Related records not syncing.'''
-> This is either because the related fields aren't on your sync layout, or that you haven't actually [[TriggeringRecordMods | triggered a modification in the parent record]].
Added lines 1-4:
!! Processing the inbox
For errors processing the inbox in GoZyncHosted, see [[processing errors]].
For errors processing the inbox in GoZyncHosted, see [[processing errors]].
Changed line 7 from:
-> Coming soon.
to:
-> More coming soon.
Changed lines 3-41 from:
!! How can I be sure my iPad / iPhone can see my FileMaker Server/ Host?
-> If you've gotten the External Data Sources between Mobile.fp7 and the hosted files ( GoZyncConnector.fp7 and GoZync.fp7) working in Pro, they'll work on your iOS device, provided your device can see your server/host. Not being able to see the host is usually only a problem for folks testing this on their local machines (people with IP addresses beginning 192.).
-> To test the visibility of your FileMaker Server / Host, you don't even need GoZync, you just need FileMaker Go on your iPhone or iPad:
--> Switch wifi off so the device is connecting to the internet over cellular.
--> Open FileMaker Go and get to the main "files" screen. In the right half of the screen, click the plus sign to add a host. Enter the IP address or name of your FileMaker Host and click "save". If you see files, or get asked for an account / password, your server is visible from outside the local network.
-> If you host isn't visible, check out the build in help for FileMaker Pro or FileMaker Server to learn about opening ports and exposing your server. You might also consider a third party hosting provider like %newwin% [[http://www.pointinspace.com | PointInSpace]].
!! Making sure updating new versions works?
Here is how you can be sure that the copy of your mobile file on your devices can [[DistributingMobileFiles | download new versions]] of itself.
-> '''1.''' Delete the copy of Mobile.fp7 on your iPad. Remember, renaming the mobile file is fine but: GoZync keeps a separate version number for each file name. So "Mobile.fp7" on your iPad can only download new versions of that file name: if you've renamed Mobile.fp7 to "MyFile.fp7" you need to first get a copy of "MyFile.fp7" on your iPad and the GoZync's new version routines will work with "MyFile.fp7". The rest of these instructions use "Mobile.fp7" but substitute your file name here if you've renamed it.
-> '''2.''' Quit FileMaker on the desktop and rename the Host folder as described above.
-> '''3.''' Open Mobile.fp7 locally in FileMaker Pro and visit the New File Prep layout to send a new version to the server: if you get errors you may need to double check the External Data Source references in Mobile.fp7.
-> '''4.''' Once you have a new copy up there, close Mobile.fp7 and email yourself a copy of Mobile.fp7: you'll open this email on your iPad and then it will be installed in FileMaker Go.
-> '''5.''' Now open Mobile.fpy back in FileMaker Pro (keeping the Host folder renamed to xHost) and visit the New File Prep layout to send one more new version to the server: this will be one version higher than the one you emailed yourself.
-> '''6.''' At this point you can return to Mobile.fp7 on your iPad and click "Check for new version", downloading the build you uploaded in step 5 above. At this point you know that the file references in Mobile point to your served files. If you get an error here it is likely because your iPad can't see your FileMaker Server: it is behind a firewall or has a private IP address. Follow the instructions in FileMaker Server's built in help to open ports or otherwise expose your server / host to the outside world.
!! I can't upload a new version, it says "File Can Not be Created on This Disc"
-> It is likely that the privilege set you're logged in as does not have export rights: either log in as a full access user or extend the privileges of the account you'd like to use.
!! I'm getting more records than I should be.
-> If you're trying to zync 10 contacts (for example) and are getting many more than that, take a look at the resulting records in table view. If you see some of the correct contacts, but then a lot of records that only have the primary key (and none of the other values) it is likely that one or more of your SetField scripts is actually setting a field in the wrong table occurrence. In this contacts example, you get extra contacts by having any one SetField step from another table's Set Field script accidentally set a filed from a Table Occurrence based on Contacts.
-> If, on the other hand, you see lots of real contacts in there in addition to the ones you expected, then it is likely the found set in your source that is the problem: the found set just has the wrong records. See [[downloading found sets]] for more info.
to:
-> Coming soon.
Added lines 1-4:
!! General Gotchas
-> GoZync uses SQL so you can't use reserved SQL words for any table occurrences or fields. You can't have a table occurrence named "time", for example.
-> GoZync uses SQL so you can't use reserved SQL words for any table occurrences or fields. You can't have a table occurrence named "time", for example.
Changed lines 31-32 from:
It is likely that the privilege set you're logged in as does not have export rights: either log in as a full access user or extend the privileges of the account you'd like to use.
to:
-> It is likely that the privilege set you're logged in as does not have export rights: either log in as a full access user or extend the privileges of the account you'd like to use.
Changed lines 35-37 from:
If you're trying to zync 10 contacts (for example) and are getting many more than that, take a look at the resulting records in table view. If you see some of the correct contacts, but then a lot of records that only have the primary key (and none of the other values) it is likely that one or more of your SetField scripts is actually setting a field in the wrong table occurrence. In this contacts example, you get extra contacts by having any one SetField step from another table's Set Field script accidentally set a filed from a Table Occurrence based on Contacts.
If, on the other hand, you see lots of real contacts in there in addition to the ones you expected, then it is likely the found set in your source that is the problem: the found set just has the wrong records. See [[downloading found sets]] for more info.
If, on the other hand, you see lots of real contacts in there in addition to the ones you expected, then it is likely the found set in your source that is the problem: the found set just has the wrong records. See [[downloading found sets]] for more info.
to:
-> If you're trying to zync 10 contacts (for example) and are getting many more than that, take a look at the resulting records in table view. If you see some of the correct contacts, but then a lot of records that only have the primary key (and none of the other values) it is likely that one or more of your SetField scripts is actually setting a field in the wrong table occurrence. In this contacts example, you get extra contacts by having any one SetField step from another table's Set Field script accidentally set a filed from a Table Occurrence based on Contacts.
-> If, on the other hand, you see lots of real contacts in there in addition to the ones you expected, then it is likely the found set in your source that is the problem: the found set just has the wrong records. See [[downloading found sets]] for more info.
-> If, on the other hand, you see lots of real contacts in there in addition to the ones you expected, then it is likely the found set in your source that is the problem: the found set just has the wrong records. See [[downloading found sets]] for more info.
Changed lines 31-37 from:
It is likely that the privilege set you're logged in as does not have export rights: either log in as a full access user or extend the privileges of the account you'd like to use.
to:
It is likely that the privilege set you're logged in as does not have export rights: either log in as a full access user or extend the privileges of the account you'd like to use.
!! I'm getting more records than I should be.
If you're trying to zync 10 contacts (for example) and are getting many more than that, take a look at the resulting records in table view. If you see some of the correct contacts, but then a lot of records that only have the primary key (and none of the other values) it is likely that one or more of your SetField scripts is actually setting a field in the wrong table occurrence. In this contacts example, you get extra contacts by having any one SetField step from another table's Set Field script accidentally set a filed from a Table Occurrence based on Contacts.
If, on the other hand, you see lots of real contacts in there in addition to the ones you expected, then it is likely the found set in your source that is the problem: the found set just has the wrong records. See [[downloading found sets]] for more info.
!! I'm getting more records than I should be.
If you're trying to zync 10 contacts (for example) and are getting many more than that, take a look at the resulting records in table view. If you see some of the correct contacts, but then a lot of records that only have the primary key (and none of the other values) it is likely that one or more of your SetField scripts is actually setting a field in the wrong table occurrence. In this contacts example, you get extra contacts by having any one SetField step from another table's Set Field script accidentally set a filed from a Table Occurrence based on Contacts.
If, on the other hand, you see lots of real contacts in there in addition to the ones you expected, then it is likely the found set in your source that is the problem: the found set just has the wrong records. See [[downloading found sets]] for more info.
Changed lines 27-31 from:
-> '''6.''' At this point you can return to Mobile.fp7 on your iPad and click "Check for new version", downloading the build you uploaded in step 5 above. At this point you know that the file references in Mobile point to your served files. If you get an error here it is likely because your iPad can't see your FileMaker Server: it is behind a firewall or has a private IP address. Follow the instructions in FileMaker Server's built in help to open ports or otherwise expose your server / host to the outside world.
to:
-> '''6.''' At this point you can return to Mobile.fp7 on your iPad and click "Check for new version", downloading the build you uploaded in step 5 above. At this point you know that the file references in Mobile point to your served files. If you get an error here it is likely because your iPad can't see your FileMaker Server: it is behind a firewall or has a private IP address. Follow the instructions in FileMaker Server's built in help to open ports or otherwise expose your server / host to the outside world.
!! I can't upload a new version, it says "File Can Not be Created on This Disc"
It is likely that the privilege set you're logged in as does not have export rights: either log in as a full access user or extend the privileges of the account you'd like to use.
!! I can't upload a new version, it says "File Can Not be Created on This Disc"
It is likely that the privilege set you're logged in as does not have export rights: either log in as a full access user or extend the privileges of the account you'd like to use.
Changed lines 1-2 from:
!! How can I make sure updating new versions works?
to:
!! How can I be sure my iPad / iPhone can see my FileMaker Server/ Host?
-> If you've gotten the External Data Sources between Mobile.fp7 and the hosted files ( GoZyncConnector.fp7 and GoZync.fp7) working in Pro, they'll work on your iOS device, provided your device can see your server/host. Not being able to see the host is usually only a problem for folks testing this on their local machines (people with IP addresses beginning 192.).
-> To test the visibility of your FileMaker Server / Host, you don't even need GoZync, you just need FileMaker Go on your iPhone or iPad:
--> Switch wifi off so the device is connecting to the internet over cellular.
--> Open FileMaker Go and get to the main "files" screen. In the right half of the screen, click the plus sign to add a host. Enter the IP address or name of your FileMaker Host and click "save". If you see files, or get asked for an account / password, your server is visible from outside the local network.
-> If you host isn't visible, check out the build in help for FileMaker Pro or FileMaker Server to learn about opening ports and exposing your server. You might also consider a third party hosting provider like %newwin% [[http://www.pointinspace.com | PointInSpace]].
!! Making sure updating new versions works?
-> If you've gotten the External Data Sources between Mobile.fp7 and the hosted files ( GoZyncConnector.fp7 and GoZync.fp7) working in Pro, they'll work on your iOS device, provided your device can see your server/host. Not being able to see the host is usually only a problem for folks testing this on their local machines (people with IP addresses beginning 192.).
-> To test the visibility of your FileMaker Server / Host, you don't even need GoZync, you just need FileMaker Go on your iPhone or iPad:
--> Switch wifi off so the device is connecting to the internet over cellular.
--> Open FileMaker Go and get to the main "files" screen. In the right half of the screen, click the plus sign to add a host. Enter the IP address or name of your FileMaker Host and click "save". If you see files, or get asked for an account / password, your server is visible from outside the local network.
-> If you host isn't visible, check out the build in help for FileMaker Pro or FileMaker Server to learn about opening ports and exposing your server. You might also consider a third party hosting provider like %newwin% [[http://www.pointinspace.com | PointInSpace]].
!! Making sure updating new versions works?
Added lines 1-15:
!! How can I make sure updating new versions works?
Here is how you can be sure that the copy of your mobile file on your devices can [[DistributingMobileFiles | download new versions]] of itself.
-> '''1.''' Delete the copy of Mobile.fp7 on your iPad. Remember, renaming the mobile file is fine but: GoZync keeps a separate version number for each file name. So "Mobile.fp7" on your iPad can only download new versions of that file name: if you've renamed Mobile.fp7 to "MyFile.fp7" you need to first get a copy of "MyFile.fp7" on your iPad and the GoZync's new version routines will work with "MyFile.fp7". The rest of these instructions use "Mobile.fp7" but substitute your file name here if you've renamed it.
-> '''2.''' Quit FileMaker on the desktop and rename the Host folder as described above.
-> '''3.''' Open Mobile.fp7 locally in FileMaker Pro and visit the New File Prep layout to send a new version to the server: if you get errors you may need to double check the External Data Source references in Mobile.fp7.
-> '''4.''' Once you have a new copy up there, close Mobile.fp7 and email yourself a copy of Mobile.fp7: you'll open this email on your iPad and then it will be installed in FileMaker Go.
-> '''5.''' Now open Mobile.fpy back in FileMaker Pro (keeping the Host folder renamed to xHost) and visit the New File Prep layout to send one more new version to the server: this will be one version higher than the one you emailed yourself.
-> '''6.''' At this point you can return to Mobile.fp7 on your iPad and click "Check for new version", downloading the build you uploaded in step 5 above. At this point you know that the file references in Mobile point to your served files. If you get an error here it is likely because your iPad can't see your FileMaker Server: it is behind a firewall or has a private IP address. Follow the instructions in FileMaker Server's built in help to open ports or otherwise expose your server / host to the outside world.
Here is how you can be sure that the copy of your mobile file on your devices can [[DistributingMobileFiles | download new versions]] of itself.
-> '''1.''' Delete the copy of Mobile.fp7 on your iPad. Remember, renaming the mobile file is fine but: GoZync keeps a separate version number for each file name. So "Mobile.fp7" on your iPad can only download new versions of that file name: if you've renamed Mobile.fp7 to "MyFile.fp7" you need to first get a copy of "MyFile.fp7" on your iPad and the GoZync's new version routines will work with "MyFile.fp7". The rest of these instructions use "Mobile.fp7" but substitute your file name here if you've renamed it.
-> '''2.''' Quit FileMaker on the desktop and rename the Host folder as described above.
-> '''3.''' Open Mobile.fp7 locally in FileMaker Pro and visit the New File Prep layout to send a new version to the server: if you get errors you may need to double check the External Data Source references in Mobile.fp7.
-> '''4.''' Once you have a new copy up there, close Mobile.fp7 and email yourself a copy of Mobile.fp7: you'll open this email on your iPad and then it will be installed in FileMaker Go.
-> '''5.''' Now open Mobile.fpy back in FileMaker Pro (keeping the Host folder renamed to xHost) and visit the New File Prep layout to send one more new version to the server: this will be one version higher than the one you emailed yourself.
-> '''6.''' At this point you can return to Mobile.fp7 on your iPad and click "Check for new version", downloading the build you uploaded in step 5 above. At this point you know that the file references in Mobile point to your served files. If you get an error here it is likely because your iPad can't see your FileMaker Server: it is behind a firewall or has a private IP address. Follow the instructions in FileMaker Server's built in help to open ports or otherwise expose your server / host to the outside world.
