FM8A: $ 10 * 1 = $ 100'000

[rpp]

Test file and screenshot attached.

Why doesn't FM8A recalculate the Total?

It recalculates it only after changing the layout (twice) or changing the window size.

Why doesn't it recalculate this field?

Thanks.

test.zip

Edited January 19, 2006 by Guest

[Martin Brändle]

Because you defined Total by a sum over a self-join. It will update only when you commit the record in the test file, table portal.

It's better you define Total in the test_start table , e.g. Total = Sum (portal::Sub Total). Then it will update immediately when you change either price or quantity of the single items.

[rpp]

It will update only when you commit the record in the test file, table portal.

FM8 Help:

> Unlike most word processing applications, FileMaker Pro saves your data as you work. This is called committing data. Data is committed when you:

...

> - [color:red]click anywhere outside of the current field

...

I click [color:red]outside the 'Price' field, it becomes inactive, Sub Total in the portal is recalculated correctly. But no changes in Total.

[comment]

When you click outside of the the current field, data IN THE CURRENT RECORD is committed. Data FROM RELATED RECORDS is kept in a cache. Filemaker does not consider changing data in a twice removed related record a good reason to update the cache.

[Martin Brändle]

Click into field Total in the file test, layout portal, then outside of it. It will update.

The problem is the self-join. Difficult to explain, but no record was committed in TO (table occurence) portal2 on which the summation depends. From where should TO portal2 know which record has changed in TO portal? All the key values are the same in the 1:1 relation used, hence TO portal2 is not in a defined state, e.g. the record pointer for the records in TO portal2 is somewhere, but probably not at the record where you committed the change in TO portal. It has no reason that its record pointer runs through all its records to see which record has changed (and that's why no change is reported back), unless you click into field Total to force the summation to update.

It's similar to a dead-lock situation in parallel programming, where you have two processes that depend on each other. Say process 1 is in state A and needs as condition that process 2 is in state D that it can reach state B. Process 2 is in state C and needs as condition that process 1 is in state B in order to reach state D. Both wait for each other infinitely, unless one changes externally the state of one of the processes.

Remove the self-join, and define Total as I said before.

[Martin Brändle]

Good and short explanation, comment (and an example of parallel answering (= processing) where we worked on the same question without knowing from each other. Now I can correct my answer based on your committed answer ).

My explanation is probably wrong. I see just a problem because in his example current record = related record. It looks like the FM engine does not communicate the change to TO portal2, e.g. the info in the cache, although it should, because the timestamp of the committed record is more recent than that of the same record in the cache. Bug? The click into the unstored summation finally forces to get all most recent data.

[comment]

It's only a screen refresh issue. The data is in place, and if an evaluation is called, the correct data will be retrieved. There's a very long discussion of this here, but the gist of it is that Filemaker does not monitor related records for changes. Perhaps even better way to put it would be: Filemaker does not monitor unreferenced related records for changes.

In any case, the solution is as you have indicated.