FileMaker provides a number of default auto-enter values for specific fields such as creation date, time, account name, timestamp and the less used name - as well as their modification equivalents.

When creating a solution which is used in more than one time zone it is desired to know when records were created or modified relative to a singular time. This can be accomplished with FileMaker's Get ( CurrentHostTimeStamp ) function within an auto-enter field.

Follow these steps to implement or simply copy and paste from the Standards.fp7 or Standards.fmp12 file.

creationHostTimestamp

Follow the settings within these dialogs.

Note: The check box for Do not replace existing value of field (if any) is checked for the creation field but not for the modification field.

When using GetField ( Null ), the calculation is always evaluated and forces the call to the Get ( CurrentHostTimeStamp ) function. This is useful for time based calculations and audit logging.

The modification version of the field varies only in the setting of the Do not replace check box (which is disabled) and its reference to the modificationTimestamp field.

  • No labels

6 Comments

  1. Anonymous

    Wouldn't 

        Let( 
          trigger = GetField ( "" ); 
          Get( CurrentHostTimeStamp )
        )

    be easier? One less field to manage.

     

    Richard (dd@dyce.com)

    1. Jeremy Bante

      I didn't believe it when I saw it, but it did work when I tested (in both FileMaker 11 and 12). I like it. I'm not sure why the creationHostTimestamp needed to reference another field in the first place, but I like fewer modificationTimestamp fields. For my own part, I think I'll be adopting this in the first modificationTimestamp field with the understanding that it's the host timestamp, and just ditch the modificationHostTimestamp name. Now if we can just get FileMaker to document and support the Get ( UTCmSecs ) function so we can use that instead of Get ( CurrentHostTimeStamp ) long-term, we'd be able to ride to work on unicorns or something awesome like that.

      1. Matt Petrowsky

        It was referencing the modification field because this value would always force the evaluation of the calc based on the record creation itself. However, if a given solution or table does not opt to use modification timestamps then it's great to know that GetField() will always force a calc re-eval! Thanks for that one Richard!

        I wouldn't ditch the modificationTimestamp because you lose any opportunity to do a time diff based on different zones from the user and server.

        Granted, all of the fields regarding creation or modification are optional - but they always end up sneaking in eventually even when you don't initially add them.

        I'll update the Standards files and the pictures here.

  2. Anonymous

    It's a neat trick that you can use for all sorts of re-calcs. Writ large, you can use it (sparingly) to replace calculations with auto-enter calcs. Very useful.

  3. Anonymous

    Just for fun, here's a link to a toy file:

    https://www.dropbox.com/s/cv2bs5g8ww5k5h6/Toggle%20Mod%20Stamps%20Toy.fmp12.zip

    It illustrates a couple of things:

    1. how to turn on/off modification globally; v. useful for updating data via scripted import without altering mod stamps
    2. how to see user-edit timestamps vs. scripted timestamps. This can be useful for checking intra-chair-keyboard issues (wink) and then let you reset the scripted timestamps to last user edit timestamps.

    Richard (dd@dyce.com)

  4. Daniel Smith

    It was recently pointed out to me by LaRetta that there is no need for using the GetField function in the creationHostTimestamp field's auto-enter calc, just Get ( CurrentHostTimeStamp ) will do the same thing.