Sum ( portal::field ) don't get the value before commited, but List ( portal::field ) do.
So validating with calculation on any "master" field
Evaluate ( Substitute ( List ( detail::num ) ; ¶ ; "+" ) ) = 0
seems working as expected, if the portal doesn't have filter. (tested only FM12)
IMHO you would be better off with a full transactional scripted approach instead of relying on calculations for this. You will have much more granular control and will be able to validate the things you need without having to worry about when calculations update.
Will give it a try. But why not just use the summary field totaling the detail amounts, as described above? What am I missing.
Not exactly sure what you mean, most likely do to my lack of FM experience. I need to be able to see detail amount totals before committing the record, so I will need some sort of total field on the portal.
I see a lot of recommendations for using a calculation field in the master table that sums the detail amounts. But that field is not updated until the records are committed, and this is too late.
I am not sure what the downside to using a summary field (defined in the detail table) which appears to be updated prior to committing the records. Just need to refresh the object or window to update the display.
I think you are correct, I wrote for some reasons
- Your post had no reply some while, will be forgotten
- I don't like summary field
- I use calculation to validate if it is able, script trigger is attached to layout, so don't run on another layout. (But I feel "List() work in same context but Sum() not" is far from logical...wimdecorte just wrote something may be better Re: Commit Records/Requests vs. Refresh Window ...)
- I'm not experienced at FM13, haven't used Refresh Object many times
- Refresh Window is felt for me updating something not wanted, at least ODBC table will be committed (of course this is not your problem).