About relationship predicate order making a difference

Heads-Up!
1

Today I got a strange behavior from a set of 3 TOs all linked like this:
A → B → C

I was having trouble displaying portal records from C on a layout based on A. A and B are related via a constant_1 = constant_1 relationship.

I created a layout based on B and the portal was displaying the info I expected. The same portal on both layouts was not displaying the same information.

Changing the first predicate comparison operator from = to <> gave the good data on layout/portal A and now gave the unexpected result in layout/portal B.

I removed the first predicate and added it back to as the last predicate, and now both layout/portal combination show me the expected result.

I can now replicate this at will if I flip the order of the predicate in the relationship. This while using FM17 on macOS 10.12.5

I would most definitely consider this a bug. :bug:

2

What are the predicates on B -> C ? Can we replicate this for our testing?

3
  • constant_1 = flag.isTask
  • constant_1 <> task.isCompleted
  • userFilterAsGlobal = username

The first field can be 1 or blank
The second field can be 1 or 0
The third field can be a name or be blank

For it to work, I had to take the first predicate and make it the last one instead.

As described earlier, if I change the first predicate operator (instead of making that predicate the last one) to <>, A now sees a child record in C despite the fact B, for the exact same values, does not see the child record.

4

FMPA v17.0.7.700
Mac OS X 10.15

created a new file using the Tasks template. Created a new table "viewer" to act as table A. Used the existing table "Assignments" to act as table B. Used the existing table "Tasks" to act as table C. Created fields and set up relationships as you've described.

Generated records in Tasks and Assignments and Viewer.

In testing, the predicate order of the relationship does not matter.

PredicateTests.fmp12 (532 KB)