4 Replies Latest reply on Oct 31, 2012 5:13 PM by Vaughan

    Slow Scrolling - FM Pro and FMS 11

    user12837

      I have a layout with 600 records and ten fields, many of which are calculations in related tables. At present, scrolling is very slow. I would like an on open script which freezes the window until all calculations for all 600 records have been completed, so that the user can then flip through the records as if they were on a spreadsheet. I tried looping through all the records, but that doesn't do it.

       

      Thanks,

       

      Tom

        • 1. Re: Slow Scrolling - FM Pro and FMS 11
          taylorsharpe

          Basically, you want it to build the cache first before using the layout.  I don't think looping through will help unless as it loops through, it is refreshing or doing some calculation on fields you want cached.  It may be as simple as sorting the calculation field that needs a cache built, but then again, you may have multiple fields that need cached.  Also, while looping through won't work, down page downs through it probably will, but only in 11 and not in 12. 

          • 2. Re: Slow Scrolling - FM Pro and FMS 11
            Mike_Mitchell

            Hello, Tom.

             

            FileMaker doesn't work like that. What you're describing is a consequence of how FileMaker refreshes and loads records. There are two primary things going on here. One has to do with the loading of the records themselves; the other has to do with the refreshing of unstored calculations.

             

            I'll ask this question: Is this database being hosted by FileMaker Server over a network? Because if it's not, then the record loading issue doesn't make any difference, and we can skip it entirely. Otherwise, we can look at it.

             

            When you say, "... calculations in related tables", I'm going to assume you mean unstored calculations (because if they were stored calculations, you likely wouldn't see what you're seeing). Unstored calculations only refresh their values when they're needed - for example, when they're being displayed to the user. (Other times include when they have to be evaluated as part of a relationship - on the parent side - or in order to evaluate another calculated expression.) They're not stored in the database, but only in the cache - and they require updating whenever the conditions that drive their values change (not that they are necessarily updated then; they just require updating).

             

            So, freezing the window - or even looping through the records - will likely not help much, especially in a multi-user environment (you haven't indicated whether this is true or not, but it's a consideration). What we probably need to look at instead is either (a) making your calculations more efficient (so they update faster), or (b) finding a way of storing their results (so they don't have to be updated on the fly). The latter option is counseled by some developers, but others are ... enthusiastic opponents for a variety of reasons.

             

            So, short version: Perhaps if you posted some sample calculations, or a copy of the database, we might be able to help you look at them for optimizing purposes.

             

            Mike

            • 3. Re: Slow Scrolling - FM Pro and FMS 11
              Vincent_L

              If your users only need to see the data, and not manipulate them, if they don't need to interact with them, no buton, then you can render everything in html in a webwiever, and that's super fast to scroll.

              • 4. Re: Slow Scrolling - FM Pro and FMS 11
                Vaughan

                It could be isues with the interface design. Duplicate the layout and strip it right back: remove script triggers, conditional formatting, graphics, everything. Test for speed now. If it's better then work out what's causing the bottleneck.