I think you might want to be adding the sum of both related data shown in the two portals. Your current calc would only reference the first two portal rows.
Sum ( Purchase Orders::Contract Amount ) + Sum ( Change Orders::Running Sum )
If I am reading your problem correctly. Does that help?
It would be helpful to clearly describe the relationship of your tables., e.g. is ChangeOrders a child table for PurchaseOrders (one PurchaseOrder have many change orders)?
And why do you need a running total?
Change Orders and Purchase Orders are child tables of the Jobs table. Each job contains PO's and CO's and the database is designed to track the activity and increase in original subcontract sum per job. I need to calculate the total of change orders by job, and each job has one to several CO's, each causing an increase to the original contract sum. The portal pulls in the co's by job, and the running sum keeps my totals changed when a new one is added to the database. One the CO's increase the orignal sub, tracking PO's helps to ensure that each additional cost was covered.
Sorry if I'm bad at explaning this....I've got it working in some records beautifully; it simply does not carry over into all records as I understand that it should.
Sorry if I'm bad at explaning this
No, it's fine. There was only the crucial omission of the Jobs table, which would be the context I mentioned.
Using related summary fields can be tricky, and it's often easier to use the aggregate functions.
Try re-defining your calculation field as
PurchaseOrders::amount + Sum ( ChangeOrders::amount )
(assuming that according to your business rules, every job will always have just a single PO; otherwise use Sum() there, too); since it's an unstored calculation, it will update properly, and should work on every Jobs record.
(If you want to show the CO sum seperately, e.g. beneath the portal, create a summary field Total of amount (not! running) in ChangeOrders and use another, one-row portal into ChangeOrders to display it. That's where using a related summary field is not so tricky …)
That's not to say a calc field is the optimal solution, simply because the field is unstored and, depending when and where you need the result, performance may suffer (e.g. when scrolling through a list of Jobs where this field is displayed).
Once you got it working as such, you could become adventurous: make the calc field a normal number field and use a script trigger and a Set Field script with the above expression to keep the field up-to-date whenever you change the amount field (or delete the PO or a CO).
Thank you Thank you!!!! Im trying it now and understood it perfectly! Well explained!