We had a contractor set us up using GoZync. We have over 300 users that regularly sync data back to our server. We continually get a small percentage of those users where FM GO pops up an error message reporting that either the solution file or GozyncMobile is damaged.

I've already searched this forum under some related keywords and come up empty so I'm guessing that our contractor may have supplied us with files that have latent corruption that is causing this steady trickle of "file is damaged" errors. It's producing a significant drain on our support resources as we work with users to replace GoZyncMobile and to salvage the data in the solution files. (Recover the file, import into new copy, send file back to user).

So I have to ask: are there any known issues with either FileMaker GO or GoZync that would produce damaged files? (I have a lot of FM GO files of my own design on my personal iOS gadgets and they certainly don't come up with such an issue, but they also aren't designed to sync back to a server either...)

Looks like we may have to do a complete file replacement with a new solution, but need to be sure we really have to do that before we take that route...

We see this occasionally when files are closed when FMGo considers them in-use: much as a desktop crash can cause a local file to be flagged as having been "closed improperly". I believe syncing exacerbates the chances of this as files are open during a sync where users may switch to another app, close Go, sleep the device, etc. while a sync script is running or while hosted files are open.

The only behaviors we've found to stop this are a) to never close the files/sleep the device during sync, and b) to set GoZync so that the hosted files are closed after sync. You can change that setting at line 26 of the script "Finish Sync" in GoZync Mobile.

If it helps, this doesn't seem like the "lingering corruption" issue as when we're seeing this it's a few devices out of dozens using the same file, much as you're describing.

Personally, I think FileMaker should be doing a better job of protecting the local file, or provide a way past "closed improperly" on Go.

Thank you. Given the 300+ users, this is also something that happens for a very small fraction of the total number of users. It's just that even a small percentage adds up for us given that many users.

We can do some user education on this subject short term and work on modifying the script as a long term improvement. We are in transition to a new contract developer for this so the user education option--however imperfect, can reduce the frequency while we work with the new developer to produce an updated/modified copy of GoZyncMobile so that it closes the file as the final step.

Is it possible that a connection loss mid synch could exacerbate this? I'm thinking that the synch might fail and the user then quits FM GO mid synch to try again later.

FWIW, Of all the times that I've recovered one of these "damaged" files, I've only had the recover process come up with a report of something fixed one time. All the other times, recover found nothing wrong--which suggests that either an index was screwed up or some other setting that recover restores to "factory spec" without checking it for damage was the source of the "file is damaged" report.

After consulting with others on my team, we have another question:

Which files should be closed after the sync completes?

Our developer indicates that he already has the system closing the hosted files so we are wondering if the files local to the iOS device should also be closed after sync has completed?

Sounds good. I was specifically talking about the closing the hosted files. But having a big "close" button on your local file's layouts (and on GoZyncMobile) is probably a good idea since people aren't used to the difference between "closing a file" and "quitting an app" in iOS.