Why do you need to edit transactionUUID ?
It is the key for relation for the portal, so usually it shouldn't be edited once related records are created in portal.
If you want to relookup, you need to do it on SubTransactions::transactionUUID.
I don't need to edit the field, it's just according to the script guide - the field must be an editable field for the relookup to work. Relookup fails on SubTransactions::transactionsUUID as well.
Regardless I moved on to using a script with Replace that works well enough.
Have you tried using a summary field in the SubTransactions table instead of an aggregate Sum calculation in the parent table?
I need the data aggravated by each record in the budgetMonthSubTransaction table, so no....
So put the summary field there. It can - and probably should - go at the lowest level.
I'm not at my computer so I can't poke at that approach, but I'm conceptually trying to understand the advantages of using a summary now that I have the aggragation field working properly for both initial entry and updates.
Using a summary field, IIRC, is going to give me an aggravation based on sorting the records. I don't thinks that's going to meet my intended use, but I may play with it when I get the chance. Since this is a personal project, my time to work on it is limited.
Basically the goal is to have a monthly budget per budget account. As certain types of income arrive, it will get allocated against the budget. The purpose of the aggregation field is to provide a way to tell how much income as already been allocated against the budget for the month so that I can see how to allocate additional income as it arrives.
I will probably do this from a global context that relates to the budget accounts through month/year.
The summary field will give you the value when sorted on the break field … in the table where it lives. But a summary field is not dependent on being sorted. (Try this: Put a summary field in the footer, unsort the records, and watch the results.)
When you use a summary field on the child side of a relationship, it gives the parent record the value of the summary for the records that are related to the parent. So if I put:
on my parent layout, it will give me the summarized result of all the records in relatedTable that are children of the current parent record.
So why not use a Sum ( ) (or other aggregate) function? Well, a couple of reasons. First, the summary field in the child table will be useful in any table that points to it (including itself), whereas the aggregate in the parent would have to be duplicated for every parent table and every relationship. Much smaller footprint. Secondly, the summary field has other uses besides just aggregating child records. You can use, for example, the GetSummary ( ) function to get an aggregate of that table’s information based on any sort field you desire. The aggregate in the parent can’t do that.