1 2 Previous Next 15 Replies Latest reply on Dec 20, 2012 1:50 PM by Matty_1

    portal display issue



      portal display issue


           I've crated a database for our dispatching crew where I store all the jobs in one table and have a "VIEW" table that consists of 8 portals per record.  Each record represnts a calendar day and each portal repsents a delivery location.

           5 of the portals are set to show the record if the drop location is equal to designated location for that one portal and has the same date as the record in the VIEW table. A 6th portal is set to show any records that do not show any of the drops designated in the first 5. 

           Exmaple: Dispatch::ULLocation  ≠  "DropA"  and Dispatch::ULLocation  ≠  "DropB" and Dispatch::ULLocation  ≠  "DropC"  and Dispatch::ULLocation  ≠  "DropD"  and Dispatch::ULLocation  ≠  "DropE"

           The last two portals show records from a completely different table in our buying a selling portion of the datebase (no issues on the last two).

           When adding a new job, you select from a list of contracts and select submit.  The script remembers the contract number, goes to the contract table, finds the contract, remebers all the jobs associated to the one contract and then goes to the job table and creates all the jobs copy pasting all the appropriate infomration.

           When we create a job that fits the critteria of one of the first five portals it appears instantly after hitting submit.  When we create a job that doesn't fit any of the first five criteria therefor defualting to the 6th portal there is a long delay before it appears in the portal.  Somtiems minutes other times seconds.


           Any idea why this would be happening??

        • 1. Re: portal display issue

               It sould like you need to add a commit record request after adding a new job.  This should casue the portal to update.

          • 2. Re: portal display issue

                 No this does not work.  Even when I go to a completely different layout on and completely different tablr and come back there is still a delay.

            • 3. Re: portal display issue

                   Try adding to the end of your script.

                   Refresh Window[Flush Cached Join Results]

              • 4. Re: portal display issue

                     Yes, Refresh Window[Flush Cached Join Results] should do the trick. When you change the value of a field used in a portal filter expression, the records in the filtered portal do not update automatically.

                     But Refresh Window[Flush Cached Join Results] can represent a major performance hit on your system in many cases and should thus be avoided.

                     You can, however, modify your relationship on which this portal is based to eliminate the need for the Refresh Window[Flush Cached Join Results] script step.

                     Go to Manage | Database | Relationships

                     Find the relationship line for the relatinship that enables this portal and double click it. Add the Dispatch::ULLocation as a match field matching by the X operator instead of = to any field in the other table.

                     This should force the portal to update when the value in this field is changed without the need for a script with Refresh Window[Flush Cached Join Results] in it to get the portal to update.

                • 5. Re: portal display issue

                       Thank you Phil, currently my relationship is based solely on the date.  


                       In the layout where I see all the dispatched jobs I have 5 records one for each day of the week.  Within each record I have 8 portals, these sort out the different job locations into their respective "columns" which are portals.  I'm thinking adding the above relationship wouldn't help me but I could be wrong.  I'm guessing I have to create a dumby field for the "X" realtionship and leave it blank??

                  • 6. Re: portal display issue

                         Pease note that Refresh Window[Flush Cached Join Results] has not fixed the issue.  There is still a considerable delay.

                    • 7. Re: portal display issue

                           I see no reason why it wouldn't work, but please note that I have suggested that you add this detail to your existing relationship. You'd keep your current match fields intact. Because the relationship uses the X operator, it won't affect what records are related, your other match field pair(s) will do that, but it will force the filtered portals to update when a field referenced in the portal filter changes value.

                      • 8. Re: portal display issue

                             I've added a relatinship from Dispatch::ULLocation and linked it to the RecordID Field on the table view using the X operator and I'm still haveing the same issue.

                             I've tried this with and wihtout the refresh window in my script. 

                        • 9. Re: portal display issue

                               Note that if I add one job alone it will not appear for some time.  If I add a second immdeiatly after the first job, the first will apear as soon as the script is complete and the other will take some time.  This continues through to the third etc. etc.

                          • 10. Re: portal display issue

                                 If refresh window [flush... doesn't work, then there's a different issue keeping your portals from updating.

                                 Now that I've read your original post more carefully, Refresh window isn't the issue. It would appear that it is working correctly, just too slowly and this would appear to be the result of your portal filter's complex filter calc being applied to a large number of related records to determine which can make it through the filter to appear in the portal.

                                 You'll need to experiment with two approaches:

                                 Try producing a relationship that matches to fewer records. If there is another pair of match fields that you can set up that greatly reduces the number of related records to filter, this portal should update more quickly.

                                 Build a relationship that eliminates the need for a portal filter at all. Here's an example:

                                 Define cExcludeList in your layout's table as:

                                 List ( "DropA" ; "DropB" ; "DropC" ; "DropD" ;"DropE" )

                                 Select Text as your return type.

                                 Then add this pair of match fields in your relationship:

                                 LayoutTable::cExcludeList ≠ Dispatch::ULLocation

                                 This will exclude all dispatch records wher the ULLocation value is one of these locations.

                            • 11. Re: portal display issue

                                   I use both.

                                   Commit Records/Request[no dialog]
                                   Refresh Window[Flush cached join Results]

                              • 12. Re: portal display issue

                                     Thank you Phil,

                                     So if I told you that the number of records in the dispatch table was 159 with only 30 or so records relating to each individual record in the VIEW layout ... leaving 2 or 3 of the 30 to be filtered into the complex filter formula would you say that this all makes sense still?  I don't find there are that many records to filter but I could be wrong.


                                     Just want to make sure you think it makes sense before I implement your changes.

                                • 13. Re: portal display issue

                                       It does seem very odd that you are getting the layout to update, but only after a very long delay. Any chance that you have some trigger controlled script involved here that is affecting what you see--perhaps without realizing that your actions are directly or indirectly (throught a script that trips the trigger) tripping such a script trigger?

                                       Also try making a duplicate of your layout and then removing all but one simple data field (no calculation fields) with no conditional formatting from the portal. See if you get the same delays with this layout. If not, then one of the details that you deleted must be responsible for the slow down you are seeing.

                                       Also, if you are using FileMaker 12, make sure you have downloaded and run the updater to update as slow screen updates are one of the bugs these updaters are supposed to correct.

                                  • 14. Re: portal display issue

                                         If you read my last post in your email, please read it again in the forum as I spotted a critical omission in it after posting. I edited the post to correct the error, but you won't see this correction in your email.

                                    1 2 Previous Next