Refresh Issue

[bruns]

Hello, I have a field called status with radio buttons

Active

Reserved

Checked Out

I have a date checked in and checked out.

The calculation is working which is when they are checked in, it shows active, future date shows reserved and checked out is of course checked out.

 

Problem is it is not refreshing, if someone checked out yesterday, it still shows reserved which tells me it never auto clicked over to active.

 

When I just sit there and put dates in and change them around it worked, so that part of the calc worked but how can it be updated?

 

Thanks

[AHunter3]

Is Get(CurrentDate) referenced somewhere, anywhere, within this architecture?

[bruns]

Here is the calc

 

 

Case (

 

not IsEmpty ( canceldate ) and canceldate

Get(CurrentDate)

Get(CurrentDate) >= Date Reserved From and Get ( CurrentDate )

Get(CurrentDate) >= Date Reserved Too ; "Checked Out" ;

"Date error"

 

)

[bruns]

AHunter,

 

I forgot to click "Do not store, recalculate when needed" is this my problem?

[David Head]

Yes, that is the problem - whenever you use Get ( CurrentDate ), you should set the calculation to unstored. That applies for a lot of Get functions to allow them to update.

[bruns]

Thanks David, I should have caught it earlier, I thought I had checked it so I did not think to look there first.

 

Thanks Steve

[poetnabotl]

Why does a text field with an auto-enter calculation function differently than a calculation field whose result is text (do not store)?

[AHunter3]

Why does a text field with an auto-enter calculation function differently than a calculation field whose result is text (do not store)?

 

 

A text field contains whatever textual data gets PUT into it. That's a verb. No action — no "PUT" — means no field value.

 

A calculation field IS the result of its formula, reconciled to the specified type. That's a noun. It simply IS what it IS. No action necessary. Or possible.

 

A stored calculation field evaluates the formula; if the various fields that are referenced in the formula have their values changed, that will trigger a reconsideration of the stored value, but parameters such as Get(SystemPlatform), Get(AccountName), Get(CurrentDate), etc, which are not fields but rather parameters referencing the outside world, if you see what I mean, don't cause the stored calc to reevalute its results every time they change, because in order for that to happen FileMaker would have to be watching all of those factors constantly. Think about Get(CurrentTime). Maybe someday the idea of FileMaker refreshing all of its stored info a minimum of once per second (for however many fields and records and tables and files it has open) will make sense, but it doesn't make sense today and that's not how it happens.

 

An unstored calculation field is still a noun, but the contents of it are a giant shrug "gee I dunno" up until the moment you ask to know the value, at which point FileMaker evaluates the calculation, gets an answer, and then does not evaluate that formula again until the next time it has reason to do so. If you put an unstored time calculation field set to Get(CurrentTime) on your layout, it does not become a clock. (But if you refresh the layout you get the time as of the moment the layout was refreshed).

 

A text field with an auto-enter calculation option is back to verbs, even though some of those verbs are "triggered", i.e., automated. If the checkbox "do not replace existing values" remains checked, the formula is evaluated when the record is created, just like an auto-enter serial number or an auto-enter creation date field, and that's that. If the checkbox is unchecked, then the local indexed stored fields that are referenced in the calculation formula, if they change, will kick FileMaker into "noticing" and the formula will be re-evaluated. But anything that FileMaker can't index — whether it be Get(CurrentTime) or Portal::FieldFromAnotherTable or LocalUnstoredCalcField — do not prompt a reevaluation.

 

A stored calculation field of result type "text" and a text field with an auto-enter option that references strictly local stored & indexed fields in its formula, come the closest to each other. But the text field is still based on a verb — you can still click into it and type "my pet kitty cat" and, barring a validation requirement stopping you from doing so, it will accept that value even though that's not at all the consequence of the formula. Because you, operating manually, are another form of the verb to PUT. The calc field, though, simply IS what it IS. It doesn't let you type in what you want.

 

 

If you're more familiar with spreadsheets such as Excel, think of it as the difference between a macro designed to fill cell C3 with a calculated value, on the one hand, and a formula field that you begin with an equal sign, on the other.

[poetnabotl]

Well explained. Thanks.