4 Replies Latest reply on Jan 28, 2015 5:07 PM by andyk3005

    Ghost Transactions in Portal Display

    andyk3005

      I was wondering whether anyone has come across this issue or can explain it.


      I have a portal which displays multiple records from file B related to a single record in file A

      I have a second portal which displays multiple records from file C related to a single selected record in the first portal.

      The header portal is linked by a relationship to file A through a key.

      The child portal is linked by a relationship to file A through a key and a global.

      I have a simple 'delete related record' on the records in each portal and an add record script for each portal.

      When I delete records from the child portal they disappear from the portal but when the focus is returned to the header record they reappear, as in the screen shot below, as ghost images since the records have been deleted.   If I select another layout and go back to the original the deleted records have gone.  I have added a work around which does this as part of the delete function but I would like to avoid this if possible.

       

      Filemaker.jpg

        • 1. Re: Ghost Transactions in Portal Display
          coherentkris

          Ask yourself what does FileMaker do when you move to another layout? At a minimum it commits the records and displays the visible fields. It processes triggers, hides objects, and conditionally formats too..Is their a commit records step in your delete script? Does your delete script have a refresh window flush cache joins step or some other method to cause refreshing of the join data? You need to programmatically replicate what FM would do without actually changing layout context.

          • 2. Re: Ghost Transactions in Portal Display
            andyk3005

            Thanks for the response.

             

            The layout is based on file A.   It has no modifiable fields. My understanding of a portal is that if a relationship exists, then the portal will display the related records automatically.    This is true when moving from one record to another in the header portal.  The child records display correctly in the portal without a commit on file A,   The global is set to the key and the records display automatically.  My problem is understanding why it is necessary in the case of deletions to commit the record from file A to have the relationship link between the Layout file A and the child file C display correctly in the portal.

            Anyway I have replaced the 'goto layout' with a commit which solves the issue but I must say that i find it rather odd.

            • 3. Re: Ghost Transactions in Portal Display
              coherentkris

              The actions that cause commit:

              Commit record script step.

              any script or user action that changes record, layout, or mode.

              any script or user action that closes window.

              click to exit field without entering another field.

               

              Delete portal row via without commit and FileMaker may not have refreshed the hidden cached join data. Commit causes refresh.

              • 4. Re: Ghost Transactions in Portal Display
                andyk3005

                Hi,

                 

                The cached data remaining unaffected by the portal delete until the base layout is committed explains the situation.

                 

                Thanks for the help.