AnsweredAssumed Answered

Refresh Portal step sometimes doesn't re-evaluate portal that has a filter, once broken it's broken for whole file

Question asked by user5135 on Jun 22, 2018
Latest reply on Jul 6, 2018 by TSGal

Product and version (e.g. FileMaker Pro 14.0.3)

FileMaker Server 17.0.2 (WebDirect)


OS and version

Windows Server 2016 Datacenter


Browser and version

Google Chrome v67.0.3396.87

Internet Explorer v11.0.9600.19036



Processor: Intel Xeon CPU E5-2660 v4 @ 2GHz (2 processors)

Memory: 8GB




Refresh Portal step sometimes doesn't re-evaluate portal that has a filter. I haven't found a way to reproduce the problem reliably, however I do know that at least the following criteria needs be met

  • A portal with portal filtering switched on
  • Portal filter calculation references some changeable data (e.g. a global variable)
  • Portal given a name
  • Portal refreshed using Refresh Portal["portalName"] step
  • Not logged in as a [Full Access] account


When first set up in a vanilla file this will work as expected. However after some usage of the file this functionality can break. Some combination of the following actions seems to break it eventually

  • Running the following steps with different options set on each
    • Re-Login
    • Show/Hide Toolbars
    • Set Zoom Level
    • Allow Formatting Bar
    • Show/Hide Menubar
    • Install Menu Set
  • Adding and editing layout objects


Once the functionality 'breaks' the portal won't refresh and the following will be the case

  • Refresh Portal["portalName"] step will have no effect
  • Refresh Window[] will have no effect
  • Refresh Window[Flush cached join results] will refresh the portal
  • If Re-Login as a [Full Access] account the portal refreshes without issue
  • If Re-Login as a non-[Full Access] account the portal fails to refresh


Once this has happened in a file the following seems to be true across the file

  • all portals in the file will fail to refresh
  • creating new TO, relationship, portal, layout, layout object - will always fail for that file


This happened in a production system after moving to FMS17. I created a vanilla file and that file took several hours of me experimenting with it before the file broke. I've created 4 vanilla files and managed to 'break' 2 of them. One of the broken files is attached in case it helps [User: Admin; Password: admin].


How to replicate

Can't replicate exactly - see above


Workaround (if any)

Use global fields to create a relationship that will achieve the same effect as the filter


Use Refresh Window[Flush cached join results] and accept the screen flashes