1 2 Previous Next 16 Replies Latest reply on May 20, 2014 9:05 AM by Datagrace

    Lots of damaged file issues


      We recently deployed a "large" Go system to +/- 30 users. Large as in ~1GB filesize. +/-35 tables with the separation model used and GoZync implemented. Three files total.


      We have had an inordinate number of the "Error "[filename]" is damaged and cannot be opened. The datafile. Use the desktop product's Recover command to recover this file." Of course the regular joe using the solution is rightly confused, concerned and annoyed. Even getting the ~1GB file is painful.


      Anyone have ideas to avert this?


      Thanks, Mark

        • 1. Re: Lots of damaged file issues



          Presumably, if you are using GoZync there is a set of files on the the device and hosted in house.Which files are getting toasted? The GO files or the in house files?



          • 2. Re: Lots of damaged file issues

            Mark,  I suspect that a 1 gb file with 35 tables might be pushing the limits of FM Go.  FM Go definitely exhibits some problem behaviors in low memory conditions.  Frequent restarting the iPad (at least once per week) helps to avoid these problems.  Highly recommend making sure your users close the files when they are finished, instead of just closing the cover on the iPad, tapping the home button or tapping the power button.

            • 3. Re: Lots of damaged file issues

              I don't believe even rebooting moves the app out of memory. To actually exit the app, from the Home screen 'push' it up after double-tapping the Home button.


              I agree that the large file size is a likely place to expect trouble. What do the GoZync people say?


              John Weinshel

              • 4. Re: Lots of damaged file issues

                I use an app called Memory Status to track the memory on the iPad.  Quittng FMGO and restarting the iPad will both clear out the memory.  I like the restart, because it frees up more memory than just quitting one App.

                • 5. Re: Lots of damaged file issues

                  How do you quit Go?



                  • 6. Re: Lots of damaged file issues

                    From your post "To actually exit the app, from the Home screen 'push' it up after double-tapping the Home button." 

                    • 7. Re: Lots of damaged file issues

                      OK, we agree on what 'exit' means.


                      If Go is running,  and I re-boot without exiting in that way, I still see Go running (if I double-click the Home button). If I am following your description, Memory Status will tell you that it is not. Is that correct?


                      I do not have Memory Status, so I cannot confirm, but it sounds useful.



                      • 8. Re: Lots of damaged file issues

                        The Data file on the Device, one of the Go files. Sync/Zync works well and I doubt that Seedcode has a role to play in this issue.


                        It could be that a larger file like this is a bit much to expect from Go, but during testing - 2 months or more worth - the 4 testers didn't have this issue. Granted it was smaller before wider use (we started out just under 500MB) but some users have never had the issue at all.


                        I do think that Go had memory issues before the 13.0.4 update but it's been much better since...


                        I think I'll get that/a memory status monitor.... Thanks all, keep those ideas coming...!



                        • 9. Re: Lots of damaged file issues

                          John, I did a little testing on my iPad.  I opened five FMGO files on my iPad.  Then I reboot the iPad.  When I opened FMGO, all five files were still open.  Then I did the same thing but instead of rebooting, I exited the FMGO App from the multi-task bar.  When I opened FMGO again, all five files were still open.  So it seems that unless you close each file separately, something is keeping the files open in the background in a suspended state no matter how you exit the App.  Next I'm going to test by leaving the iPad closed for a longer period of time to see if that makes a difference.

                          • 10. Re: Lots of damaged file issues

                            Mark -


                            The damaged file behavior often comes from the file being closed abnormally, especially during a record edit (or schema edit, but that doesn't apply to Go). I'm wondering what else is going on with these iPads. Often, mobile users are accustomed to just slapping the cover closed or hitting the Home button. If they leave lots of apps open, and memory becomes an issue, it's possible you might have iOS closing FileMaker Go or some other behavior that's forcing the files closed without proper record commits. (I see this when well meaning, but FileMaker - not-so-savvy server admins close Server from the Task Manager.)


                            Would it be worth asking the users what else they're doing on their iPads?

                            • 11. Re: Lots of damaged file issues

                              .. that is why we definitively need a Exit Application script step support for FM GO - i added this a long time ago as a feature request.



                              • 12. Re: Lots of damaged file issues

                                GoZync and other syncing methods tend to improve speed by copying data to the device.  But that means managing the data on the device which is subject to corruption for various reasons listed above.  Have you tried a non-sync'd remote connection over internet?  If the performance is acceptable, then you don't have to worry about data corruption since the data is stored on the server and not the iPad.  Ultimately, a server will always do a better job of managing the storage of data.  Traditionally FileMaker has been a client-server solution primarily where all the data has to be processed on the client making network connections slow due to having to move so much data between the client and server.  But FileMaker has been maturing so that more and more is being done automatically on the server.  And a developer can push even more processing on to the server with the "Perform on Server" function, thereby making a network connection feel a lot faster than in previous versions.  Don't get me wrong, there are times where syncing can make a solution feel a lot more like it is on a local area network.  And syncing can also let you do things when you don't even have a network.  However, lately, I find myself moving more away from syncing and more to optmizing the server and network connections.  I now do a lot of reporting via SQL and Perform on Server with results returning to a variable array table where data is not stored in the table but in a global variable. 

                                • 13. Re: Lots of damaged file issues

                                  Ok, I believe I'm getting closer.


                                  This does need to be an offline solution. These inspectors are often outside of cell phone reception and even if 3G or Edge (shudder) was available the data needs are such that a sync solution works best.


                                  That being said, I believe there are 2 types of situations they can get into that are at the root of the problems.


                                  First, after a Zync I had NOT explicitly closed the hosted GoZync files. This kept them open and when users went into an area with no cell phone connectivity they would get a 'trying to reconnect...' message. When they heard from others that merely force-quitting Go and restarting would get them back in business fastest - they did :-(


                                  I also believe that there are circumstances where a record was left Open in the solution. If this occured and they force-quit Go they would introduce corruption that may be another source of corruption. I'm actively seeking these workflows and trying to keep the situation where a record is Open to a minimum.


                                  Thanks for all of you collective ideas. Mark

                                  • 14. Re: Lots of damaged file issues

                                    Mark, are we to take it from your description that you are now explicitly closing the GoZync files?


                                    And, what makes the system so big? Is it many records, wide records, large indices, BLOBS, or some combination thereof? Where I'm headed, obviously, is 'is there a way to make it smaller?' The conventional method is to pull down only the bare minimum amount of stuff that you need, but perhaps you are already doing that. Is big because the inspectors need to compare their findings with installed data, and that installed data (all the possible types of green things, for instance, including narratives about them and pictures of them) is big? If so, could it be passed into a text stack in some form, rather than as records? Any chance you could change the architecture so that users pay more on startup than out in the field?


                                    One other point: I asked earlier what the people at SeedCode thought, and you replied that it's not a GoZync issue. I had meant that you might consider consulting with them if you can't get un-stuck. They see a lot of mobile implementations.



                                    1 2 Previous Next