It's not easy to give an answer here )-:
First of all: FMGo runs pretty stable here. Until now, never had a corrupted file. We do have (seldom) a problem with FMGo where we have to close FMGo and restart it - but we always can keep on working. Restarting the device may help as well.
When user are having problems, they often can't tell exactly what happened - but maybe there are some things in common
- What does the FM app? Only local files? (No server connections)
- file size..?
- When (on wich task) does the problem occur? (Typing text, inserting pictures/files, taking photos, after hibernating, etc)
- What other apps?
- What are people do else with their iOS devices?
- Are some of the devices 'hacked'? (Jailbreak)
- Always the same users, same (similar) situation (free space, number of apps running, the same apos, etc)?
On a iOS device, one can rarely check (no log files available to end users, no system-check app's, etc).
One technique that has been very useful to me is to define a global text field that I name gDebug and a global number field name gDebugFlag
Then, I seed my scripts with code like this:
If [ Globals::gDebugFlag // debug mode is on ]
Set Field [ Globals::gDebug ; List ( Globals::gDebug ; "ScriptNameHere " & "Field/variable names/values here" ]
I can then use FMGO on my iPhone for a while until I get the problem response I am investigating. I then switch to a layout that fills the screen with gDebug and review my "trace" of what events led up to the issue. You might be able to adapt this method for the issue described here so that when the user comes to you with the screwed up file, you can review his most recent activities to see if you can spot any common patterns from one case to another.
I know finding answers to such general inquiries is hard, I appreciate anything that gives me a lead!
- What does the FM app? Only local files? **It's a front end to access our main database.
- file size..? **Initially it's a 9mb file, but it saves copies of all the orders sent to it, and the pictures as well, so it can get up to a couple hundred MB. The last broken one that came in was 1.2gb from months of use, and repaired down to 700mb.
- When (on wich task) does the problem occur? (Typing text, inserting pictures/files, taking photos, after hibernating, etc) **Doesn't seem to be a specific task, though our users aren't tech savy enough to notice. It seems they exit the app cleanly and then it just won't open the next time they go into it.
- What other apps? ** A random assortment of iPhone apps. Some users keep a very clean phone, some have lots of games on there. My co-worker thinks that any games are somehow corrupting the file, I think that if unassociated apps are corrupting a FM database our problems are much more severe than we think.
- What are people do else with their iOS devices? ** Some users are strictly business, some treat it like a personal iPhone. Both end up with corrupted databases eventually
- Are some of the devices 'hacked'? (Jailbreak) **Nope, none.
- Always the same users, same (similar) situation (free space, number of apps running, the same apos, etc)? **No, the only thing that's uniform amongst the devices is they're iPhone 4 through 5c, usually have the latest iOS, and the other app we install by default is Voxxer. Apart from that, they do their own thing.
On a iOS device, one can rarely check (no log files available to end users, no system-check app's, etc). **That's the problem I'm running into. Plus, when the DB is corrupt and I repair it with Filemaker, it doesn't report any errors, even though it compacts the file and makes it work. If it would at least tell me what the heck was wrong I'd be able to do... something.
I'm just guessing but the phone may be getting full. Check the available space on the phone. I'm not sure the amount of space that is required but I'm sure it depends on the size of the database. Filemaker create indexes as needed and maybe there is no enough space to complete the indexing and maybe the reason that running recover fixes the issue, it re-indexes and compacts the database.
That was our first guess, but this happens on fresh phones with >10GB free. Unless FM is doing some reeeeaaallllyyy funky stuff, I can't imagine it's creating temporary indexes that large.
The next time you get a corrupt file (before you run recovery) place a post on "Report An Issue" and sent a copy to Filemaker so tech support can take a look at the file. Filemaker employees have TS in the front of their user name.
Yes.. size matters. The files that are in daily use here are smaller, 10-20 MB. I'm also aware that the iOS version of FM is much slower than the desktop version (in some tasks). Could be a factor too.
Is the front end connecting to the main db over the internet (LAN)? Any chance that a transaction 'hangs'?
I agree with S. Chamblee - have the TS' check a corrupted file