Re: Refreshing calc (sum) fields

In article <061220071844253668%helpful_harry@xxxxxxxxxxxxxxxx>, Helpful
Harry <helpful_harry@xxxxxxxxxxxxxxxx> wrote:

In article
<516eb0fe-8d6e-4190-b645-ce7a8637fea1@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Grip <grip@xxxxxxxxxxxxx> wrote:

On Dec 5, 4:54 pm, Helpful Harry <helpful_ha...@xxxxxxxxxxxxxxxx>
wrote:
In article
<98a0d974-0ff4-4dc7-88b1-640c0da96...@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,



Grip <g...@xxxxxxxxxxxxx> wrote:
On Dec 5, 1:28 pm, Chris Brown <cbr...@xxxxxxxxxxxxxxxxxxxxxxxx>
wrote:
Carla wrote:
In a "Bookings" table, I have a calc field, "TotalBookingCost",
which
is defined as "sum ( BookingLines::BookingLineCost)", i.e. it's the
total of the costs of the individual lines that make up the booking.
BookingLineCost is also a calc field, based on rates, duration, etc.

I have a layout based on Bookings, with a the related BookingLines
in
a portal. All well so far. But if the individual costs in a
BookingLine change in the portal, the value in TotalBookingCost is
not
updated.

It seems I can force a refresh by a variety of means, such as
toggling
the Status Area off and on, switching to a different layout, etc.,
but
I'm sure I shouldn't have to. Any ideas what I'm doing wrong?

(FM9, PC)

Carla

define the calc as unstored

also consider trying the line item calcs as number/auto enter
calculated
value, with do not replace existing value unchecked.

The calc will have to be unstored if it's referencing a related table.

I've seen FM be slow on the uptake in refreshing unstored values. It
could be that you're not committing the related record or it could
just be a gremlin. It helps to have a trigger. You could put a button
labelled "Refresh" or "Update" or some such and attach a script to
it. That script should include the steps:

Commit Record/Request
Flush cache to disk
Refresh Window

Yep, it must already be unstored, so there's only two possible answers
... well, three if you include a corrupted file.

Either the user is still in the field they've just changed, in which
case FileMaker has actually got that change yet. They have to leave the
field for the change to be taken into affect.

OR, it's the silly "non-committing" of records that newer versions of
FileMaker now have, which apparently the only way to fix is to have a
script as you've just written above that forces FileMaker to accept the
new changes to the record. :o(

It's not a non-commiting error, the data is committed, but the
unstored calc doesn't get refreshed. And it's not just newer
versions...I haven't used 6 in a few years, but unstored fields need
something to trigger their refresh, even in 6. An unstored calc field
= Status(CurrentTime) doesn't just tick off the seconds like a system
clock, it needs an event to trigger it (like a screen redraw or a
forced refresh), no?

Semi-true.

An unstored Calculation field that is set to grab the current time will
only update when the layout is refreshed ... BUT an unstored
Calculation field that sums other fields WILL refresh (once you leave
the altered field) when any of the source fields' data is changed.

For example, in older versions of FileMaker:

- create three Number fields (Num1, Num2, Num3)

- create an unstored Calculation field
= Num1 + Num2 + Num3

- put all four fields on a layout and enter some data
into Num1, Num2 and Num3

- the Calculation field will display the total

- go back to Num2 and change the data - the total doesn't
change

- Tab out of the field (probably into Num3) or click
anywhere to exit the field or record, and the total
changes

If you put the "current time" Calculation field on the same layout it
will not update unless you refresh the window (usually by going to the
next record).

The problem is that newer versions of FileMaker have this silly
"non-committing" problem (based on what I've read since I haven't used
them yet) where changed data is not actually saved when you exit the
field, and therefore Calculations don't change either. :o(

*BUT*
having re-read the original question I've thought of another, more
likely, reason why it may not be updating.

Oops!!! Forget that last paragraph - I meant to delete it, but pressed
"Post" by accident. :o\ I have not got another reason for the
problem, I misread something in the original.

Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)
.