Relationships using calculations that user data from other tables

[uemtux]

Something weird guys.

I've been working in FM for a few years now, I started with 8.5 and learned early on that relationships don't work if the implicated fields are calculations that reference fields in other tables.

Recently, a colleague of mine who is new to FileMaker and didn't know about this restriction has made a few relationships using calculations that referenced other tables, and the weird thing is they WORK.

They don't work with the get related records script step, but portals seem to work fine, and scripts that read values from fields in the related table pull the correct related record value.

Does anyone know if there is an official explanation of this behaviour, or is it just a filemaker quirk that we shouldn't rely on in our solution?

Thanks!

[comment]

Hard to say anything about your colleague's example, without having any specifics. In general, unstored calculations cannot be used as matchfields on the "other" side of the relationship - usually, that is the many side of a one-to-many.

[uemtux]

The unstored calculations are on the ONE side of the relationship, the records they are matching on the many side are composed of regular fields.

As I said, using a script to get related records fails, but portals and scripts reading fields in the MANY table seem to behave as expected.

My question, which I'd still like someone to answer, is can I rely on this behaviour staying the same? My colleague wants to use it in a script that calculates shipping costs so this method failing to work for any reason could potentially be pretty bad.

[Kilyaaan]

The unstored calculations are on the ONE side of the relationship, the records they are matching on the many side are composed of regular fields.

.... portals and scripts reading fields in the MANY table seem to behave as expected.

My question, which I'd still like someone to answer, is can I rely on this behaviour staying the same?

Yes this is perfectly fine - the one side of the relationship can be unstored.

Its the many side that needs to be stored - like a regular field.

As I said, using a script to get related records fails, but ... scripts reading fields in the MANY table seem to behave as expected.

This you have to explain, I can not figure out what you want the script to do that it can't, since you say it is capable of reading the fields?

[comment]

The unstored calculations are on the ONE side of the relationship, the records they are matching on the many side are composed of regular fields.

This should work just fine, as long as you are using the relationship in one direction only - the direction from one to many.

And there is no reason why a Go to Related Records [] script step designed to get the related set on the many side should fail.