2 Replies Latest reply on Nov 20, 2013 9:29 AM by philmodjunk

    Buggy behavior, restart iOS, buggy behavior, restart iOS....



      Buggy behavior, restart iOS, buggy behavior, restart iOS....


           This one is odd, isn't likely to be something easily reproducible, yet I've now had the same behavior twice. This WAS with the same file, so I'll be doing the usual checks for file damage, but the fact that I can't repeat the issue even with the same file makes it hard to tell if file damage might be the culprit here. (A full on recover does not detect any problems.)

           I'm mainly posting this to see if others have seen similar behavior so that we can check for any possible patterns and also so that TSGal and Co. can search their database and report back if they have anything there that matches.

           Here's the details:

           I've been playing with a simple FM GO inventory database. I have some fields where I usually just need to increase or decrease the value in the field by 1. So I've set up buttons to tap that do the increment and decrement. The scripts pass a script parameter that is used in an indirect field reference to increment the field. The typical parameter looks like this: GetFieldName ( Table::FieldName ). This method ensures that if I rename the field or the table occurrence, I don't have to update the parameter expression.

           The script performs a single script step:

           Set Field By Name [ Get ( ScriptParameter ) ; GetField ( Get ( ScriptParameter ) ) + 1 ]

           Now on two different, widely separated points in time (month or more), I got the following buggy behavior:

           When I tapped the button, the field was set to 1 instead of being incremented. That's truly odd because the script step obviously was able to correctly evaluate Get ( ScriptParameter ) in the first Set Field parameter, but not in the second.

           I was all set to report this as a bug the first time around but chose to do some more testing first. I forget all the details, but ultimately, I was able to correct the problem by powering my iPhone down and turning it back on.

           But now, last night, I got the same exact thing happening again. I made a number of tests back and forth and can list the following details:

           I have two scripts that use this method. One increments and one decrements. Both failed in the same way: One assigned 1 the other -1 instead of incrementing/decrementing. (and yeah, I could pass one more item in the parameter and then use just one script, but that's what I have at the moment...)

           The buttons and scripts work normally when clicked in FileMaker Pro.

           And when I hosted the file with FileMaker Pro and linked to it as a Go WiFi client, things got really weird: I tried manually editing the field that was being modified by the button. Doing so triggered an error message that the file was already open for editing in a different window. (Not the case, I checked by tapping the window icon in the upper left corner and I didn't get the error when I reproduced the steps in Pro and this error went a way after the restart...)

           And the changes that I could make to the field via the Go Client where not appearing on the same layout on the Pro host. Nor did they persist on the client if I closed the client down and re-opened.

           And to fix it, all I had to do was Power my phone down and re-open it.

        • 1. Re: Buggy behavior, restart iOS, buggy behavior, restart iOS....

               I had a similar problem, that produced the same error message that the file was already open for editing in a different window.  I was running the db locally on my iPhone.  I worked 3 or 4 days trying different things, and I don't know what I did to fix it, because I couldn't duplicate the problem and I was busy so I didn't have time to track down.  Now several months later I don't remember everything I tried.    

               I think it has to do with filemaker Go, not releasing all resources when the db is suspended or Go not resuming the use of these resources when the app is started again. (When the home button is pressed)  I'm not sure because I couldn't replicate the error.

               When I have had unusual errors, rebooting the phone or double tapping the home button and then closing Filemaker Go, seem to fix the problems. 


          • 2. Re: Buggy behavior, restart iOS, buggy behavior, restart iOS....

                 I am aware of the fixes, just puzzled by a script step that only "breaks half way" when this happens and am not thrilled with the possibility that an FM GO DB might require paying customers to implement such fixes just to use a database that I sold to them...

                 And I'm documenting this just in case it prompts a useful response from the TS staff to look into something that needs correcting...