I do not see why you don't just use Gross Qty as your match field in place of Gross Qty autoentry. I do not see the purpose of Gross Qty autoentry at all. What does having that field accomplish that your Gross Qty cannot be used to do?
But if you have both Gross Qty and Gross Qty autoentry defined in the same table where the auto-enter calculation defined for the second field references the first field, just clearing the "do not replace existing value" check box should do the trick.
You could also define this field as a field of type calculation instead of as an auto-entered calculation field and it will then always update, but can still be used as a match field in your calculation.
As you know the calculation field "Gross Qty" refers to another table "Distribution", which is not indexable. And non-indexable field can't be used as key for the relationship to reference to my Pricing table. That's why I try to have another auto-entry field. But even I clear "do not replace existing value", the Auto Entry field value is not updated when I simply update my "Distribution" table's qty. I see the calculation field is always updating.
Your are right. I just simply switched the match field to the Gross Qty, and it works !!
I don't know why I had so strong impression that calculation field (unstored and non-indexable) can't be used as match field. I am sure FileMaker had this kind of alert somewhere before? Am I right?
As you know...
I did not know
But even I clear "do not replace existing value"...
Please note what I posted previously: "if you have both Gross Qty and Gross Qty autoentry defined in the same table." This is not the case in your situation.
I don't know why I had so strong impression...
Fields that do not have an index, unstored calculations and global fields, cannot always be used as match fields in relationships. They tend to produce "one way" relationships so it depends on the "context" in which you need to have the relationship function as to whether or not such a field can work as a match field. When you have this relationship:
TableA::MatchFieldA = TableB::MatchfieldB
If, from the context (starting point) of TableA, you need to access data from related records in TableB, MatchFieldA does not need to have an index as the value of MatchFieldA is matched against the index of Matchfieldb in order to determine which records in TableB are related. In your case, the "context" is a row of your portal, so a relationship using an unindexed match field in the portal's table to match to related records in another table will work.
While the poster does not explain what is meant by the "right side of the relationship", the info posted there IS correct once you understand the meaning of that phrase.