It sould like you need to add a commit record request after adding a new job. This should casue the portal to update.
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.
Try adding to the end of your script.
Refresh Window[Flush Cached Join Results]
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.
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??
Pease note that Refresh Window[Flush Cached Join Results] has not fixed the issue. There is still a considerable delay.
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.
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.
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.
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.
I use both.
Commit Records/Request[no dialog]
Refresh Window[Flush cached join Results]
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.
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.
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.