> Will this last step 'Commit' the changes in BOTH Invoices and Customers? And what if there were Set Fields looking into 5 or even 10 other related tables? Would ALL those changes in ALL those related tables be committed with one commit?
Yes to all these questions.
The Commit Record step does exactly what it says - it commits the whole record, which means it commits all of the data fields in that record, including any related data fields that may be displayed in that record.
Nick- Thanks. But the issue I'm concerned about is for those related fields that are not displayed on the layout. In my example, Customers::Count of Invoices is a related field, but may NOT be on the layout. This is what bothers me. In the FMP support doc that we both read, it says, "When you change related data (such as displayed in a portal), these changes are not committed until you commit the record that is displaying the related data." And, if the related field is NOT on the layout (like in my example), I contend that the related field will NOT be committed. I remain worried about this, and am still puzzled. I have researched this extensively and can NOT find the definitive answer. Also, I haven't yet figured out a way to test this.... Thanks, Mike
Mike, I think you're worried about nothing. I mean, have you ever had a situation where a related field (whether displayed on the layout or not) had not committed?
In any case, looking at your original post, it looks like you want to count the number of invoices each customer has. But rather than using an indexed field that's incremented by 1 with each new invoice, why not use a Summary field to count the number of invoices on the fly? Then you won't have to worry about whether the "Count of Invoices" field has committed or not.