unstored calc in relationship

[ddinisco]

It my understanding that an unstored calc can be used only the parent side of a relationship...correct?

I am getting zero results in my portal when I do so. If I change that field to regular number field, all works fine. I have checked the calc and it is working fine too.

[RalphL]

Try putting the field on the layout it isn't. Unstored calculations are only made when needed. Try refreshing the layout. It may not show if the portal was drawn before the calculation was made.

[comment]

It would help to know some details about the actual calculation, and about what's on the other side of the relationship. Most likely the problem has nothing to do with the calculation being unstored.

[ddinisco]

The purpose of the relationship to setup a filter for a portal list to display only items with a certain keyword. On the parent side of the relationship is:

Case(PatternCount ( keyword ; gListFilter ) ≥ 1; 1; "")

on the child side is a constant value of 1.

[comment]

Perhaps we mean different things when we say "parent" and "child". The way you describe it, you would either see ALL records in the portal or none, depending on the condition being true or false.

[ddinisco]

I am referring to the parent as the left side of relationship dialog.

The purpose is to simply filter only the records that contain the global keyword in the keyword field. So I would show 3 of 50 or 10 of 50...

[comment]

I am referring to the parent side as the one that is "looking" for children to show in a portal. That may be not a good definition in general, but I think it can be used here ("left" and "right" sides have lost their meaning when version 7 came out).

So if I understand correctly, you have the unstored calculation in the table which is supposed to supply the records to show in the portal - and that won't work.

[ddinisco]

That is correct. The unstored calc is in the same table with the data to be displayed.

[comment]

Then you need to rethink your approach. It wouldn't have worked well with PatternCount() anyway, because a filter by "port" would also show "sport", for example.

[ddinisco]

That is actually the way I want it to work, just need help with getting the relationship right.

[comment]

I think the only way to make it work this way is the so-called "Ugo method":

Define a calculation field cCondID =

Case ( PatternCount ( keyword ; gListFilter ) ; SerialID )

(where SerialID is the unique ID field of the table).

Define a self-join relationship matching cCondID to SerialID, and point the portal to the new occurrence of the same table.