4 Replies Latest reply on Aug 20, 2015 2:46 PM by philmodjunk

    Stale Portals



      Stale Portals & the Separation Model


      Imagine if you will! A pretty typical (I think?) order database. See the attached image.

      The portal contains LineItems. Upon typing in a SKU, LineItem::Product ID (not displayed) is looked up from Product by SKU. LineItem::Price is then looked up from from Product.. The portal also contains related data from other tables.

      This all works as expected until the Separation Model screws it up!

      With the interface in a separate file, everything works OK if you create a new portal row by entering the SKU first. But if you enter a Qty and then the SKU, related data like Stock::Level doesn't appear until the window is refreshed. Lookups still take place, though!

      Some forum searches reveal the separation model is prone to this kind of thing, but I haven't found other references to the order of data entry making a difference. This is weird to me. My solution is an OnTimer Refresh Window triggered by modifications of the SKU field, but this is hokey and I'd like something better.

      Should I stop worrying and love the OnTimer?


        • 1. Re: Stale Portals & the Separation Model

          That doesn't look like a "lookup" where data is copied from the related table, but a direct reference to the field fro the related table.

          But in either case, I'd consider a script trigger performed script rather than install on Timer.

          • 2. Re: Stale Portals & the Separation Model

            It has both; the Price column is in the LineItem table, and it's looked up from Product. That works fine. The Products::SKU and Stock::Level columns are displaying fields from those related tables.

            The only difference between the two lines in the screenshot is that the first was created by entering a SKU followed by the Quantity, and the second was created by entering a Quantity followed by the SKU.

            It's downright unnatural, I tell you. I can upload the example file somewhere if anybody cares to look at it.

            • 3. Re: Stale Portals & the Separation Model

              Oh, and I used an OnTimer because I hijacked an existing script that triggered OnObjectValidate, and refreshing before the field is even validated is silly. The more reasonable approach would surely be to refresh in a script triggered OnObjectSave.

              I'm just trying to avoid explicit refreshes, without regard for the trigger mechanism.

              • 4. Re: Stale Portals & the Separation Model

                But if you can trigger the needed refresh edit by edit, the result is much smoother--even if you have to do it before you validate or as the last part of an OnObjectValidate performed script, than you'd get with a timer controlled update.

                Sometimes you can get the update that you need by "goosing" the parent record's match field. This is done by using set Field to set the field to the value that the field already has. This somehow seems to trick fileMaker into doing some updates--often just enough to get what you need.

                And FileMaker 14 has added a much needed refresh portal option....