Can't filter portal based on a global

[jasonwood]

New FMP11 Portal filtering feature does not seem to work when filtering based on a global.

Here are some calculations I tried entering in the "Each portal record will be visible when:" dialog...

IsEmpty (Table::globalfield) or ( PortalTable::field = Table::globalfield )

...all records show up regardless of what is in Table::globalfield

IsEmpty (Table::globalfield)

...no records show up, even if the global field is not empty

PortalTable::field = Table::globalfield

...no records show up, even if fields match

BUT - change globalfield to a regular field, and everything works as expected (related records only show up in the case of a field match or when field in main table is blank... why would this be?

[bruceR]

PortalTable::field = Table::globalfield

...no records show up, even if fields match

This DOES work. You may have to do a refresh to see it though.

[jasonwood]

the attached file demonstrates how it does not work for me.

I am using FMP 11.0v1 MAC. Also tried FMA 11 MAC but didn't confirm version.

portaltest.fp7.zip

[Søren Dyhr]

It should apparently still be solved this way - see attachment!

--sd

portaltestfix.zip

[jasonwood]

Thanks.

But yikes... the whole point of the new portal filtering feature was to avoid all that. Seems like a completely unnecessary limitation to me... would this not be considered a bug?

Also Bruce said it works... so I'm wondering if it's just the Mac version?

Edited March 19, 2010 by Guest

[bruceR]

the attached file demonstrates how it does not work for me.

I am using FMP 11.0v1 MAC. Also tried FMA 11 MAC but didn't confirm version.

No, your attached file demonstrates that it DOES work for you.

It works correctly as is. But a refresh is required as I mentioned before. I had added script trigger refresh.

portaltest.fp7.zip

Edited March 19, 2010 by Guest

[Søren Dyhr]

Since the solutions might be deployed in a multiuser enviroment, should each refreshing be forced thru to prevent stuffing the network with chatter, your take on the matter originates from spreadsheets which can't be shared ... the layout event is what trigs the establishment of relations.

The calculations engine cannot monitor arbitrary values changing a relation away - what if there are many which to choose, but if you put the global field in the same table as you monitor can you force it thru ... this is more or less what we call Ugo's method.

--sd

[jasonwood]

ok, sorry, I thought clicking in the background, changing layouts, or committing records would constitute a sufficient "refresh".

I wasn't familiar with the "Flush cached join results" option.

I don't understand why it is any more onerous on the calculation engine to monitor a global over a regular field (which works without this script step), and would be interested if that could be explained, but anyhow I'm glad to know the work around!

Many thanks!

[bruceR]

But the global IS in the same table. It's just a standard refresh issue. You complicated solution is old-think. It is not an FM11 filtered portal.