1 Reply Latest reply on Jan 8, 2014 10:38 AM by TSGal

    BUG (Empty) Chart object on input layout causes FM to calculate VERY SLOWLY - EVEN AFTER DELETING...

      Summary

      BUG (Empty) Chart object on input layout causes FM to calculate VERY SLOWLY - EVEN AFTER DELETING THE CHART!

      Product

      FileMaker Pro

      Version

      fm11.0v4

      Operating system version

      Windows

      Description of the issue

      The FileMaker chart object has an issue, that causes FileMaker to slow down - incomprehensibly:

      - When the pie chart is in "current record" mode and is on a layout with many fields/objects...
      - ...EVEN WHEN THE CHART DOES NOT REFERENCE ANY FIELDS of the current record...
      - …changing a field in a portal to a related table (table in an external file, field upon which many calculations in the related table are calculated) CAUSES THE CALCULATIONS/SAVING OF THE RECORD TO BE VERY SLOW (=Several minutes instead of 2 Seconds)

      - It seems that the more fields and objects on the current layout the slower it is
      - Each chart seems to cause extra slowness
      - This slowness occurs EVEN AFTER THE CHART HAS BEEN DELETED FROM THE LAYOUT!
      - Only after a Refresh+Flush script step is performed, or the layout is first left + returned to is the slowness gone.

      => We have had to remove FileMaker Charts from our solution because of this problem.

      NOT BEEN TESTED IN OTHER VERSIONS/PLATFORMS

      We have spent around A WHOLE YEAR trying to find and identify the cause of this crippling performance problem! Pinpointing and removing the problem is worth tens of thousand of euros in saved customer contracts, so we would be grateful if this issue could be dealt with with respective priority.

      Thank you

      MrWatson

      Günther Business Solutions GmbH FBA

      Steps to reproduce the problem

      The issue occurs in a complex database with the following conditions (we haven't tested under other conditions, so we can't say if it occurs in a one-file solution):


      1. Set up a complicated database with lots of calculation fields, for example a database to calculate price quotes with typical Order & LineItems tables (however in 'old style' with 2 files and one-table per file):

      1.1 File/Table 1: Order.fp7 with one table "Order"
      1.1.1 External Ref + Related TO to LineItems
      1.1.2 Add lots of fields to Order, inc. calculation fields which sum the line items, etc.

      1.2. File/Table 2: LineItems.fp7 with one Table "LineItems"
      1.2.1 In LineItems add field Product ID, Qty, ItemPrice, then add lots of fields performing calculations on Qty and ItemPrice, like Indiv. Customer prices, discounts, … (the more fields you have the greater the visible slowness)

      2. Create a simple layout in Order.fp7 (with auto-save record changes)
      2.1 With a few fields from Order, and
      2.2 With a (create) portal to the LineItems table
      2.3 Add Product, Qty, ItemPrice input fields to the portal

      3. Add some data

      4. Create a complex layout (Duplicate the layout in Order and add lots of stuff, fields, portals to the layout - we had 6 statistics portals for production planning incl. complex date-range)

      5. Change the contents of the field Qty in row 1 of the line items portal and see how long it takes

      6. Add a pie chart to the complex layout:
      6.1. Create a pie chart on the layout
      6.2 Select current record
      6.3 Set labels to "a¶b"
      6.4 Set data to "1¶2" // NOTE: the chart itself references NO fields!

      7. Change the contents of the field Qty in row 1 of the line items portal and see how long it takes to save the record.

      8. Duplicate the pie Chart multiple times, and test changing Qty field again.

      9. Save a copy of the database.

      10. Delete all the pie charts, and test changing Qty field again.

      11. Go to another layout, then return to this layout, and test changing Qty field again.

      12. Reopen the saved copy, and test changing Qty field again.

      13. Perform script step refresh and flush cache, and test changing Qty field again.

      Expected result

      7. After changing Qty saving the record should be just as quick as in Step 5.
      8. After changing Qty saving the record should be just as quick as in Step 5.
      10. Given the problem with the chart object, I would expect the slowness caused by the chart object to disappear once the chart object has been deleted from the layout.
      11. Given problem 10, I don't really know what to expect here.
      13. Given problem 10, I don't really know what to expect here


      MAIN EXPECTATION:

      The presence of a chart on a layout (particularly one that does not reference any fields!) should not affect the speed of calculations IN THE RELATED TABLE (IN ANOTHER FILE!)

      Actual result

      7. After changing Qty saving the record is (much) slower than in Step 5 - the more complex (fields on) the layout, the slower it is
      8. After changing Qty saving the record is (much) slower than in Step 5 - the more charts on the layout, the slower it is
      10. THE SLOWNESS REMAINS EVEN AFTER THE CHART HAS BEEN DELETED
      11. After leaving and returning to the layout the slowness is gone.
      13. After performing flush cache the slowness is gone.

      ACTUAL RESULT:

      The presence of a chart on a layout (also one that does not reference any fields!) DOES affect the speed of calculations IN THE RELATED TABLE (IN ANOTHER FILE!), particularly:
      - EACH Chart causes extra slowness
      - the more objects (fields?) ON THE CURRENT LAYOUT the more slowness in calculating/saving the record

      Exact text of any error message(s) that appear

      "$%&*!!* FileMaker" ;-)

      Configuration information

      none

      Workaround

      1. remove filemaker charts from the layout and leave the layout
      2. use xmChart
      3. (maybe) don't mix charts and input fields on the same layout: create fm-chart on internal layout, copy contents to media field, display media field on the input layout => no slowness