March 22, 200916 yr 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.
March 22, 200916 yr 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.
March 22, 200916 yr 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.
March 23, 200916 yr Author 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.
March 23, 200916 yr 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.
March 23, 200916 yr Author 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...
March 23, 200916 yr 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.
March 23, 200916 yr Author That is correct. The unstored calc is in the same table with the data to be displayed.
March 23, 200916 yr 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.
March 23, 200916 yr Author That is actually the way I want it to work, just need help with getting the relationship right.
March 23, 200916 yr 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.
Create an account or sign in to comment