if Child::c_Price Tier is an unstored calculation field then that is your problem. You can not have an unstored calc on the child side of a relationship.
If you are looking to constrain child results in a portal on a layout based on the parent table then a portal filter calc might be a better solution.
Also you said this was a self join.. is Child in fact a TO based on the same table as Parent?
thanks. That's a good idea. I'll try that.
The field in the child table is not an unstored calc. It's stored and
The field on the parent side is a global. I've done some experiments that
may tell a more experienced FileMaker developer the root of the problem.
I can make this work if I change the value of the parent global field to a
single value (e.g 3 or 4, etc.) without referencing a value list. It
doesn't work if I add another value manually.
If I change the parent global to reference a value list and choose only one
value, it doesn't work - even if I manually enter the values in the value
list rather than referencing another field or value list from another file.
So - it seems that the value list is the culprit.
It's a mystery to me. Does this explanation give you any ideas?
Often with value lists, it is helpful to display a copy of the same field ( your global field in this case ) nearby, and do NOT attach a value list to this field. This lets you actually see what your value list is entering into the field.
"If I add another value"
How do you "add another value"? I can read that several ways.
And as Bruce hinted at, your value list may be entering a value different than what is displayed if it is a "use values from field" value list as the value list can be set up to display a "name" value, but enter an ID. Setting up an Edit box formatted copy of the same field would reveal that as you'd see the actual data entered when you select a value.
You need to make your "Parent::g_price_tier" field type text, not number. That way, you can have multiple carriage-return-separated values in it.
As you can see from the screenshot below, this relationship works if I have
one value in the global field but does not work if more than one value is
g_price_tiers is on the layout twice. Once using a checkbox set with Value
list and once as a normal edit box.
I want the relationship to match records in the child that have any of the
values in the global from the parent. 3 or 4 in the example below.
I feel like I've done this successfully a hundred times before but it's not
working in this case ... yet.
On Tue, Mar 7, 2017 at 1:12 PM, RobWestergaard <email@example.com>
image.png 250.1 K
Looks like g_price_tiers is not of type text.
Try using ≤ or ≥ (can't remember which) instead of = as your relationship operator.
neither made a difference
In your screen shot, on the right side, does the area under the heading "All" use a portal? If so, is there a filter on the portal that references the value of Parent::g_price_tiers (specifically, something like ValueCount(Parent::g_price_tiers))? Are the numbers for Count, NPS Score, etc. summary fields from the child table instance, or calculated some other way in the context of the Parent TO? If the latter, do THOSE calclations reference the value of Parent::g_price_tiers?
Have you verified that there are values for the key field in the child table that correspond to the selected values in g_price_tiers? Have you tried rebuilding the index for the c_price_tier field? Does the c_price_tier field use a different language for the index than the default for your file?
I'd like to see a screen shot of the actual section in Manage | Relationships that you have set up for this relationship instead of the "sketch" in your original post. Something is not as expected here or it would work. Perhaps you are not referencing the correct occurrence of one of these tables. Please show the actual relationship graph and identify which occurrence is specified for your layout in layout setup and which for your portal in portal set up.
This is a self relationship so the Parent and Child are both from the same base table. The area under All is a portal into the Child table.
Three of the values in the portal are summary fields from the child table. One is an aggregate calculation.
None of these reference the global field which I added only today.
Yes. I have verified that there are values in the child table records. The language is the same and I have not tried to rebuild the index but will now.
Thanks for the help.