If you use one or more fields in a calc and one of those fields get altered, it will trip the recalculation of the calc.
You would normally use this in an Auto-enter calculation examples could be:
If you want to delete a format of a just entered value in a field you could use something like:
TextFormatRemove( Table::field ), but you can also set an other field using this, say you want to update a field 'Status'
Whenever the value in field 'Number' changes, you could use a calculation like:
if( Number=""; "Status Ready" ; "Status Ready")
Hope that helps,
Ruben van den Boogaard
Using GetField("") is indeed odd in that it evaluates at all. I do not see the real benefit over using trigger of ModificationTimeStamp which we've used for years but I would love to be proven wrong. Neither of these techniques can force a calculation (or auto-enter replace) to update if it references related data or other records within same table. It behaves as ModificationTimeStamp trigger ... seeing any change to the current record and re-evaluating the calculation at that time. It cannot see if a child value has changed unless you poke it with a stick. I suppose if you don't have a ModificationTimeStamp to use as a trigger, you can use GetField("") instead.
Would I ever use it? Not unless it has substantial benefit not yet disclosed. I've been in this business long enough to know that behaviors change and I would be weary implementing it within my solutions unless FM engineers substantiated its use. I'll stick to timestamp triggers in meantime, and follow this thread with great interest!
Thanks for chiming in. The purpose for using this technique is to only update a mod timestamp when the user, as opposed to a script, makes a change to the data. This was relevant because I have a script that updates related values on record load, and the modTimeStamp was always getting changed, regardless if there was a change to the related data. The problem with this was that it throws off our sync engine (goZync) as such relies on mod Timestamps.
That said, I am not going to use the selective modTimeStamp, favoring a solution that checks to see if the data is changed before updating the related records with a simple scripted IF branch.
Darren Burgess @DarrenBurgess
Maestro of Metamorphosis
FileMaker 11/12 Certified Developer
While I don't see any other obvious benefits to the GetField ( "" ) approach (other than what Darren mentioned)...I do suppose you could manipulate the use of it and use it to conditionally trigger a selective mod Timestamp update, or all. Depending on how you have the calc written.
Alternatively, using a global variable, I've done my own "modification" check before by using a combo of the OnRecordLoad and OnRecordCommit triggers.
OnRecordLoad script - something like this:
Set Variable $$original =
field1 & ¶ &
field2 & ¶ &
field3 & etc...
OnRecordCommit script - compare it using something like this:
Set Variable $commit =
field1 & ¶ &
field2 & ¶ &
field3 & etc...
Set Variable $count = ValueCount($$original)
set variable $i = $i + 1
if ( GetValue($$original;$i) ≠ GetValue($commit;$i) )
set field (modstamp) = get(currentTimeStamp)
exit loop if $i = $count
Set Variable $$original = ""
The above runs fairly quickly, exiting whenever the first modification comparison returns true, and gives me precise control over what "rules" I want to set to qualify as a "modification". Of course there's lots of branching out and error checking you can add in this technique as well, but I just wanted to show the core method.
That aside, I'd be interested as well to hear from Filemaker why the back end would return anything at all to a core function that had "empty" passed to it.
The purpose for using this technique is to only update a mod timestamp when the user, as opposed to a script, makes a change to the data.
In addition to a regular LastModified field (auto-enter modification timestamp), define another timestamp LastUserModified field with auto-enter (replace) calc:
IsEmpty ( Get ( ScriptName ) ) ; LastModified ; LastUserModified
... just another approach to consider ...
GetField() evaluates the value passed into it. From FMP Help...
Suppose you have the fields Arrow and Target. Arrow contains the text string Target, and Target contains the text string Bullseye.
- GetField(“Arrow”) returns Target. Notice the use of quotation marks around Arrow to indicate the literal string is the fieldName parameter.
- GetField(Arrow) returns Bullseye. Notice the absence of quotation marks to indicate the value stored in the Arrow field is the fieldName parameter.
So as you can see, passing in the text string "Arrow" evaluates as the name of the field to get, and it returns the value of field Arrow. But when you pass in the field itself (Arrow without quotes), it evaluates the value stored in field Arrow as the name of the field value to get (the text string "Target"), and so it returns the value of field Target instead.
So it's really a function for doing indirection and abstraction when needed. I would agree with LaRetta that the function was never meant to be used with an empty parameter, and may be something that will be "fixed" in a future release.
If you want a calculation to monitor other fields for changes, the Evaluate function is probably the better choice. The second, optional parameter can be a single field name, or list of field names that will trigger the calc to evaluate when any monitored field value changes. Here's the Help topic on it...