Skip to content
View in the app

A better way to browse. Learn more.

FMForums.com

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Relationships using calculations that user data from other tables

Featured Replies

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!

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.

  • Author

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.

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?

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.

Create an account or sign in to comment

Important Information

By using this site, you agree to our Terms of Use.

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.