Please can a FileMaker Tech Support person please contact us urgently regarding this. We have now isolated the problem further and have various files in different states to demonstrate the problem.
The problem 150% lies within the use of FLUSH TO CACHE commands.
Ever since FM Go 12 we have experienced issues with crashing. As a result, in other apps we have developed the use of the FLUSH CACHE TO DISK has helped reduce data loss during FM GO use. Without this command we were experiencing a lot of data loss.
In the new app we are developing --- the one where we have been able to replicate a fatal crash within FM GO, as mentioned above we have found that a number of custom dialog boxes were somehow making the app NOT crash.
The script which starts the process in turn calls numerous other scripts. Our standard practice is to issue a FLUSH TO DISK command wherever possible so we are always keeping data up-to-date because we see so many crashes.
This is the first time, however, we have been able to replicate without failure a total failure of FM GO.
We have now removed the FLUSH TO DISK commands from every script that runs through this process. This has resulted in us removing all but two of the SHOW CUSTOMER DIALOG commands.
Put another way:
The main script which starts this process was not completing before it crashed! Adding customer dialog boxes got us through that script onto the next major script. Call that Script 2, if you like. By removing ALL FLUSH TO DISK commands from script 1 we have been able to get to Script 2 WITHOUT the need to display custom dialog boxes.
We have stripped back Script 2 in the same way...and now we can make it all the way to Script 3 before the need to display a customer dialog box!
Through repetitious testing we have scaled back 7 x Show Customer Dialog boxes which guaranteed the app would not exit, down to 1 show customer dialog box! And all we have done is remove unnecessary COMMITS and FLUSH TO DISK commands.
Thank you for your post.
I'll be happy to look at the file and hopefully determine why the script is crashing. Check your Inbox at the top of this page for instructions where to send the file.
We have a similar issue here, though not as consistent as what was originally posted. I have a FileMaker Go application that has a script that loops through a series of web viewer windows as it is parsing data and sending information back to the server (this can happen once or multiple times in succession...it all depends on the data they are using on that particular day). It happens randomly, but for whatever reason, at some point in the web viewer part of the script it will exit the user to the iOS home screen. In all cases I have encountered the file is then corrupted rendering it unusable. When it happens, we have a clean copy that is loaded to the device and then it works fine (I may not see that device again for some time). We have this application deployed on at least 15 iPads and it is completely random as to what device experiences the problem. The same logic, and same file really, worked fine (no damaged files) in FMGo previous to 12 (we are running 12 now, plan to upgrade to 13 this summer). I only had the issue happen to me once during testing; in most cases, I just have staff showing up at my desk with a damaged file dialog, so I am typically not there when it happens. Anyway, with my experience, I looked through all of the data to find if there was perhaps an issue with something that was being parsed and found nothing. I took the clean copy, ran through the same data and it worked fine. All signs point to the web viewer being the issue (my experience, coupled with my queries of staff confirm that the issue appear when these web viewers are being invoked).
I'm happy to provide a file, but as I mentioned, it is a random occurrence, so I don't have a formula for repeating the issue. I was hoping that perhaps my experience coupled with the original post might help lead to an answer. Any help/guidance is deeply appreciated.
Thank you for your post.
In the file sent in by "Stefan Smith4873", it appears to be a timing issue. When a Pause/Resume Script step with a Duration of 0.3 seconds was added in the loop, there was no crash.
What else are yo doing within the Loop? Let the WebViewer load the information before extracting the data. That is, try inserting a Pause/Resume Script of Duration 0.5 seconds just prior to extracting the WebViewer data.
Keep me updated with any progress.
Thanks for the quick reply. At the web viewer layout, the loops are waiting for a response from the PHP files we have on our server (which use FX to speak to FileMaker). See sample below:
Pause/Resume Script [Duration (seconds): 1]
Exit Loop If [$Counter > Case ( IsEmpty ( Driver Route::Web Viewer Timeout ) ; 10 ; Driver Route::Web Viewer Timeout ) or PatternCount (GetLayoutObjectAttribute ( "RequestPage" ; "content" ) ; "Request Receipt Confirmation Received" )]
Set Variable [$Counter; Value:$Counter + 1]
There is a similar loop later in the script that talks to PHP after some information has been processed on Go that follows the same exact logic, just looks for a different pattern. As you can see, we have a pause for it to wait to get a response from the server, but once it gets the response, or if it doesn't after a maximum of 10 seconds, it immediately moves on. So, basically, we are just waiting to read the statement that PHP sends back "Request Receipt Confirmation Received" in the example above.
If I read/understand your recommendation correctly, perhaps I should try adding a second pause after each loop sequence to "give it a chance to breathe" before moving on? In production, this process can be quite seizure-invoking as it rolls through these web viewers (depending on the # of records to process)...perhaps if circumstances are right, it can get caught up on itself. I'll try adding another pause after each web viewer/loop sequence to see if that helps.
I will communicate the results as they are known (I expect to release a new version of our application in the next week or so).
If you already have a Pause/Resume Script step within the Loop, there is no need to add another. Plus, the Loop is referencing fields in one record.
Rather than adding another Pause/Resume Script step, just before the Loop construct, put data into a field (possibly record number) and commit the data. When the loop exits, update the field with some information to let you know the loop finished, and commit the data. This way, if the file crashes, some data will exist in the file, and you can pinpoint where the file is crashing, and it may be specific to a single record.
Continue to keep me updated.
To Marc Hill:
We have the same issue and we experience random crashes multiple times per day.
1. Do you have any FLUSH CACHE TO DISK commands in any of the scripts?
2. One of the things we know from our testing which definitely reduces the number of random crashes, is if you are able to close the database and re-open just prior to it performing this "looping script". From our observations, the crashes we experience are when there are daisy chained scripts running i.e. it is working hard, many times across multiple tables and records.
Example: We have an OFFLINE solution which synchronises to a server. When a user uploads their quotes and orders, there is a heavy duty script which is running that loads up many other scripts. This is a place where we often experience a crash. We normally experience a crash between 1 and 6 uploads to the server. However, we have found that if we close the application after 3 uploads, then re-open, upload another 3, close the database, re-open and so on, then we rarely see the crashes.
I thought we were on to something there with placing a pause after those loops. Anyway, I'll try your suggestion, but because the files have, to date, been corrupted and unrecoverable after our crashes, I'll have to engineer it so that it sends that data to the server via our PHP interaction. I wiill let you know results.
I appreciate the information. We do not have any FLUSH CACHE TO DISK commands. The phenomenon we experience has been more recent (last 6 months out of 2 years of deployment) and very random (sometimes 2 in a week; sometimes none for a few weeks). When you state that you close the application, have you engineered it to automatically close and then re-open or do you rely on staff to re-open it?
Just for clarity, the script I believe is failing pulls in a list of records via PHP and then loops through to parse them into records the device can use. As it is doing so, it communicates with the server to say, "yes I received this" and then again to say, "yes, it has been processed on the device" all through PHP which requires us to open a web viewer (and a new window) multiple times. I'm convinced that it has something to do with the web viewer because we are able to see when it is processing where it stopped at the "yes, I received this" step. For example, we have 3 records to process, the first and second go through fine with both server "handshakes" occurring, then the device crashes. When reviewing the server table that holds the handshake information, we can see that the third record did not say, "yes, I received this", and the feedback I get from our staff as well as my own singular experience, was that it failed as the web viewer windows are being open and closed. When I get a clean copy, reset the data, and try again, it invariably works fine, so it is not consistently repeatable and appears to have nothing to do with our data.
If possible, I'd like to see your file. I realize PHP code is pulling records from a server, but that action could help us determine why this is crashing on a (semi-) consistent basis. If you want to go this route, check your Inbox at the top of this page for instructions where to send the file.
Your comments are interesting! Since FMP12 we experience crashes DAILY....one of the most frequent (BUT STILL RANDOM) places it crashes is when we sync our OFFLINE solution to our server. During this process it is running multiple scripts across many tables....and opening up new windows to jump to layouts like its going out of fashion.
Our users have developed a practice as follows.
They will sync 3 jobs maximum to the server, close the database, quit to the iOS home screen, "kill FM GO", then re-open everything. If they are strict to this, we have not yet seen a crash occur during the sync process.
But, if we do not kill the application we often see crashes occur during this process.
For our newest solution which is still in development, entirely because we have found FM12 and now FM13 to be so unstable, we have changed our design methods to avoid opening multiple windows AND we have a small database file which when opened, closes the main database, then re-opens it again. In testing, these two changes give the appearance of a more stable FM13! Since our second solution is based on our first (except no code is shared; everything was re-coded from the ground up), we are not seeing the same problems when we have multiple scripts running across multiple tables. We are still testing so in practice that could be turn out NOT to be the case but in the last couple of days we tested some heavy duty data sets which we were expecting to trip it, and it did not.
If you have the ability to close the database and return to it and continue from where you left off, I would place a very large bet it would make a significant difference. In over 20,000 large sync transactions since we began using FM12, our sync 3 jobs only rule hasn't failed, and only fails when our users forget to close after the magic number 3.
During this process it is running multiple scripts across many tables....and opening up new windows to jump to layouts like its going out of fashion.
Hmmm, I seem to recall an old bug where FileMaker had a limit as to how many windows could be opened. It may even have been a limit as to how many could be opened and then closed. I'm remembering something that pre-dates the Known Bugs List so I could be remembering incorrectly and who knows if the issue still occurs with current versions or not.
There is also a known bug with windows and the correct focus that may be worth a look: Incorrect Window selected when using a Floating Window and process window
Your memory is correct. Several versions ago (FileMaker Pro 7?), FileMaker relied on the OS window management, and Windows OS was limited to 15 or 16 open windows. Mac OS did not have this limitation. FileMaker Pro changed this design limitation (as did Windows), and this is no longer an issue.
I received your file, and I have sent it off to Development and Testing for review.
I immediately received a message from Testing that Web Viewer memory usage was improved with FileMaker Go 13.0v3, so make sure you at least have this version. Regardless, Testing will be looking at your file.
In your instructions, you mentioned to load "Today". If Testing needs to continue on Monday, can you make sure there are also test records for Monday?
The request records automatically reset their "active" date...so if they are not grabbed and marked as complete today (Friday) they will be available to grab on "today" (Monday). We designed it so that our staff don't have to worry about resetting dates, etc. if the request isn't complete...so you should be all set.
We will be putting out a new release of our application soon (next couple of weeks) and at that time we will be upgrading to FMGo13. We haven't yet done so because this is some of the busiest times for the devices during the year and changing things in the middle of it didn't seem prudent.