Can you post your calc?
It sounds like you are making this overly complicated. What's the reason for using the mod count? To avoid recalculation?
Individual table calcs are like: Get ( RecordModificationCount ) as an unstored calc.
I have a script that runs only if the sum of modification is bigger that the last time it ran. Hence the need to not lose the modifications in any child records I delete.
I'm afraid I don't follow what the calc should do, especially since you have a sum() within a sum(). Can you explain in plain words what you expect the calculation to do?
As an aside, when you see numerical suffixes to fields (Calc 3, IO 3), that is very often an indication of some table / entity structure that needs to be revisited. But we can tackle that after you tell us what you expect this calculation to do.
Sorry. Here we go...
There is a calc that I want to take place only if something is modified that may affect the IO table. Relationships flow:
Calcs < IO < FeedsUsed. So, I want to sum the modifications. For Calcs and IO there is only modification to 1 record on each table. However, I needed to sum the modifications to 1 or more FeedsUsed (hence the sum inside a sum).
My current set up seems to work except when I delete a record from one of the above tables. If I do that, the modifications associated with that record disappear from the sum of modifications on the three tables. If that happens, my script that is triggered if the sum of modifications is > that the sum of modifications since the last script........the script will no longer trigger because even if there have been modifications, I've just wiped several off the sum.
Can you get around deleting the record? From a logical workflow, if you are looking into another table, if you delete a record, the view always changes. No way around that, unless you are storing the data somewhere else.
I would consider just marking the records Inactive, or marked as deleted. But no actually delete them. From relationships and calcs, you can just test for the deleted flag ( a field ), to determine to include/exclude the value.
That would prevent loss of modification counts, but I think it would cause other problems.
As an alternative, instead of worrying about the change in the 'sum' field, I think I'll build into the record deletion script a test to see if that field has been reduced below the previous value. If it has, I'll taken the 'old sum' field down by the same amount and -1. The latter will ensure the deletion means the new 'sum' field value is still greater than the 'old sum' field. That will trigger an update when the other script is next triggered.
Thank you for suggestions.