10 Replies Latest reply on May 20, 2015 2:36 PM by TSGal

    FmGo14   Crashing a Lot With all Data GONE

    Sterling

      Title

      FmGo14   Crashing a Lot With all Data GONE

      Post

      FmGo14   Crashing a Lot With all Data GONE

       

      We have several s that work Great on Mac’s and Pc’s I started with FmileMaker 3  over 15 years ago.

       But with FMGo13  we have had a lot of troubles  now FmGo 13.9 It seems a lot of the errors have been fix.

      One major Problem “getting no errors Just tossed out of FmGo 13 and 10 times more in FmGo14.  Then FmGo turns off and I’m sent to the iPad Desktop, the only thing I can do is restart FmGo ,  Waite for a consistency check and hope some of the data from my last report is there.    Some times I get “This file is Damaged and can not be opened.  So then I need to run a Recover on all files, Recovering takes a long time them the last recoard can be missing and I lost all data and photos for that report. 

             
      1.  New with FmGo14…. Loading solution’s very slow
      2.      
      3. New with FmGo14…….Solutions run very very slow……………………..
      4.      
      5. New with FmGo14……All Tabbing missing on any Layout , all fields set  to “pop-up menu”   woks OK with Fields set  to “Drop-down list”
      6.      
      7. New with FmGo14…….Slow going from one Layout to another Layout  “ …….   smoothing so simple so slow”
      8.      
      9. New with FmGo14……. Some times going from one Layout to another Layout  some of the first Layout is transferred to the 2ed Layout …see attached photo
      10.      
      11. One major Problem “getting no errors Just tossed out of FmGo 13 and 10 times more in FmGo14.  Then FmGo turns off and I’m sent to the iPad Desktop, the only thing I can do is restart FmGo ,  Waite for a consistency check and hope some of the data from my last report is there.    Some times I get “This file is Damaged and can not be opened.  So then I need to run a Recover on all files, Recovering takes a long time them the last recoard can be missing and I lost all data and photos for that report. 

      This is just a few things I found in 60 min.   Stay away from FmGo14 

      FmGo_14.JPG

        • 1. Re: FmGo14   Crashing a Lot With all Data GONE
          TSGal

          Sterling:

          Thank you for your post.

          1. Using an iPad 3 with iOS 8.3, launching FileMaker Go 13.0v9 took 7 seconds to launch, while FileMaker Go 14.0.1 took 6 seconds to launch.

          2. Solutions under FileMaker Go 13.0v9 and FileMaker Go 14.0.1 appear to run at the same speed.  Let me know what actions you are taking in your solution so I can test it here.

          3. I'm a bit confused.  Are all your fields set for pop-up menus?  Were they are a different format prior to that?  Are you trying to tab to a field formatted as a pop-up menu?

          4. I do not notice any difference in speed switching between layouts.  Do you have any layout script triggers?  If so, what are the actions of the script triggers?

          5. I have not encountered one layout overlapping another layout.

          6. You should not crash, but if FileMaker Go 14 is crashing more often than FileMaker Go 13.0v9, I would like to see a copy of your database file so I can work with it here and determine why it is crashing.  Please check your Inbox at the top of this page for instructions where to send your database file.

          TSGal
          FileMaker, Inc.

          • 2. Re: FmGo14   Crashing a Lot With all Data GONE
            philmodjunk

            It's also possible that once your file was damaged, recover failed to perfectly restore it to working order and your file has thus become unreliable for that reason.

            This is the main reason why it is still "best practice" to never put a recovered file back into use but instead to replace the damaged file with an undamaged backup copy--importing data into a clone of that backup from the recover, if necessary to get your most up to date info into a file that is less likely to have some hidden problem in it.

            • 3. Re: FmGo14   Crashing a Lot With all Data GONE
              GouGouGourami

              Sorry to pile it on, but we are seeing 3 of the same behaviors, and one additional one (so far).

              1. Haven't noticed this. Our loading speed is nearly identical.

              2. We have a couple layouts where folks enter data into 19 consecutive (tabbed) fields. In FMGo13, the user can run through these in 12.5 seconds. In FMGo14, the exact same sequence takes 22.5 seconds. Yes, we timed this.  We had multiple employees see how fast they could do it in both, and these were the fastest times. We thought it could be related to issue number 3- in order to get tab ordering at all in FMGo14 we had to change everything from popup menus to dropdown lists, but when using all dropdown lists in FMGo13 we had the exact same speed, so it isn't a function of popup versus dropdown.

              3. Yes, all of our tab ordering stopped working in FMGo14 (we use pop-up menus). I opened the solution and cleared all the tab ordering in FMPro14, re-tabbed a single layout, and still get no tabbing in FMGo14. I changed the fields to drop-down lists and the tab ordering works, but now the keyboard is popping up, the text gets highlighted, and the dropdown list is more cluttered with "Values" and an Insert function that we would simply never use. I am hoping someone can tell us how to disable that stuff, especially the keyboard. Obviously it is a list of "Values"- we don't need to tell the user that.  This might seem picky, but when we are looking for fast and simple data entry, giving people extra clutter ("Values" label) and ways to hit wrong buttons (Insert button) doesn't help the cause. The keyboard? We are trying to use popup menus, but cannot.

              4. We were thinking the speed was a factor of script triggers, but upon disabling them we still see slower speed simply when navigating among layouts.

              5. Haven't seen this.

              6. Thankfully haven't seen this yet!

              *NEW* - When adding records to a portal, in FMGo13 the first field in the last record in the portal (the most recent one you added) will pop up. In FMGo14, when you add a new record it doesn't actually show at all in the portal, the first field in the RECORD THAT YOU JUST FINISHED pops up, and then new record appears when you get to the 4th or 5th field in the record you are editing (which is the wrong one). Is there new language or practice that we need to be aware of?

              The problem we have now is that folks are upgrading to FMGo14 because they are notified of that release, and our solution isn't behaving at all, which just means more damage control. Hopefully FM will get an update released ASAP.

               

              • 4. Re: FmGo14   Crashing a Lot With all Data GONE
                TSGal

                Gou Gou Gourami:

                Thank you for your answers.

                In FileMaker Go 13, once a pop-up menu selection was made, it automatically moved to the next field in the tab order.  This is inconsistent with FileMaker Pro (all versions) as it did not move to the next field.  Therefore, this was changed in FileMaker Go 14 to be consistent with FileMaker Pro.  To get the same functionality as FileMaker Go 13, create script triggers for each of the fields formatted as pop-up menus.  Have an OnObjectModify script trigger that simply takes you to the next field in sequence.  For example, assuming Field1 is formatted as a pop-up menu and the next field in sequence is Field2, create a script "FIELD2" that has the script step:

                Go to Field [ Select/perform ; Field2 ]

                Then, for Field1, set OnObjectModify script trigger that executes SCRIPT2.

                If you have many fields formatted as pop-up menus, you will need separate scripts for each of them.

                In your "NEW" section about adding a record to a portal, I'm having some difficulty understanding the issue.  How are you adding the related record?  Do you have any sorting in the portal?  Is the record being committed before going to the next field in the portal?  Providing a test case scenario may help.

                TSGal
                FileMaker, Inc.

                • 5. Re: FmGo14   Crashing a Lot With all Data GONE
                  GouGouGourami

                  We use buttons that call a script that adds records, which appear in portals. The first step in the script is to Commit Records. The portals are just sorted by the serial number of the records, which is automatically entered when adding a record.

                   

                  • 6. Re: FmGo14   Crashing a Lot With all Data GONE
                    TSGal

                    Gou Gou Gourami:

                    Thank you for the additional information.

                    First, a correction to my previous solution.

                    As pointed out by "rgordon" in another link, you only need one script with the script step "Go to Next Field".  You can then apply this one script to each of the OnModifyObject script triggers.  My apologies for making this more difficult than it is.

                    Back to your latest post, if the first step in your script is to Commit Records, any uncommitted changes in the portal will be updated and the portal will be put in its proper order.  This will not place your cursor in the portal and no field should be active in the portal, so I need to know what steps follow that puts you in the "4th or 5th field".

                    TSGal
                    FileMaker, Inc.

                    • 7. Re: FmGo14   Crashing a Lot With all Data GONE
                      GouGouGourami

                      Sorry that wasn't clear. So it sounds like the way that we are employing Commit Records is appropriate, yes? We added that step because folks were losing data when crashing, so the theory was this would prevent them from losing anything more than the current record that they are working on. We also added a Refresh Window [Flush cached join results], because that helped an issue in a different solution.

                      Then the script adds a record, sets a couple fields, returns to the original layout, goes to the correct portal (object), then GoTo Portal Row [ Select ; Last], then Go to Field (FieldA).

                      When you do this, the record that you added LAST (the one that you just entered data for) becomes active and FieldA becomes active. You enter a couple fields of data as it walks you through with tab ordering, and THEN you see the new record appear in the portal, on the line right below the record you are working on. This happens sometimes after the FieldA is entered, of sometimes you get through 4 or 5 fields before the new record appears.

                       

                      • 8. Re: FmGo14   Crashing a Lot With all Data GONE
                        TSGal

                        Gou Gou Gourami:

                        "Then the script adds a record, sets a couple fields, returns to the original layout,..."

                        If the portal is not showing the new record, there could be a number of reasons why this doesn't occur.  Have you tried committing the record after adding the record and "setting a couple of fields"?  Then, when you return to the "original layout", is this layout based on a different table or the same table?  Is there a portal filter active?

                        TSGal
                        FileMaker, Inc.

                        • 9. Re: FmGo14   Crashing a Lot With all Data GONE
                          GouGouGourami

                          We changed where we are committing the record. There is no portal filter active. The layout is based on a different table.

                          We hacked a workaround that is very ugly, but it effectively gets us past the issue. After adding the record, it creates a new window, goes to the second to last record, changes some fields to that record, then returns to the original layout. This footwork basically recreates the steps that we needed to do manually to get the newly-created record to surface in the portal.

                          I'm really hoping that this is addressed before FMGo13 is pulled. Right now we can keep this script in the on-deck circle, but if FMGo13 is pulled from the App Store and it isn't addressed in FMGo14, this is just another one of those hacks that we'll need to incorporate. Ugly.

                          • 10. Re: FmGo14   Crashing a Lot With all Data GONE
                            TSGal

                            Gou Gou Gourami:

                            If this worked in FileMaker Go 13 but fails in FileMaker Go 14, then I would like to see the file.  Check your Inbox at the top of this page for instructions where to send the file.

                            Whenever working with related data, be sure to commit that data to ensure relationships are updated before switching layouts.  If a record is not committed, the record may not be present in portals that access the newly uncommitted record.

                            TSGal
                            FileMaker, Inc.