The trouble with modificationTS is what it responds to, in other words what it considers to be a modification. All it tells you is that something was done that modified the record (according to FM's definition) but absolutely nothing else. Nothing about what field or fields were modified; whether data was entered, or altered or deleted or otherwise tinkered with; who modified the record; nothing of any real significance. Try this: select the contents of a field; cut the contents; click inside the now empty field; paste. The field is back where it started, but the record's modificationTS will show the record was modified. If you want useful stuff you need to set up an audit trail.
How about this...
In addition to your regular auto-enter modified timestamp, you could add a second timestamp field "timestampModifiedByUser", which would be an auto-enter calc:
If ( IsEmpty ( Get(ScriptName) ) ; timestampModified ; timestampModifiedByUser )
caveat - if you have scripts that pause for user data entry in this table, timestamp won't update. but you could modify it to test for specific script names.
Keywords, in looking for info on this I saw posts from you going back years where you don't like the auto-mod-date thing and suggest an audit trail. Where a trail is needed there's no substitute, but for a lot of cases it's way overkill. A simple mod-date field and mod-by field gives me all the clues I need to solve a lot of debug issues, is a trivial amount of setup by comparison, is a trivial amount of processing by comparison, and a trivial amount of expense to the client by comparison.
Quarfie, that's a variation I hadn't considered and I like it. The thing is there are various ways I could keep a second, more manual, mod-date so I know which were my mods and which were user mods but none would be so simple as just a script call to change the attribute of the field to a non-auto-enter field, run the maintenance script, then re-enable the auto-enter attribute. There are so many things that can be changed by script I'm surprised there isn't one to do this, which is why I was hoping I was just missing it.
You can "Import records" without "perform auto-enter" to keep the mod ts field.
1) find records to be modified
2) export records to any format you want
3) edit exported records
4) import records with "update existing records" option
When you want to edit a field on a record, you can make a simple text file instead of step 2 and 3.
I have no problem with that; modTS has its place—I include one in all my tables—but I was merely pointing out its very limited usefulness. The alternate modTS approach suggested by quarfie is a good option to give an additional piece of information.
On the question that prompted you to post this, however, ("if I run a script to reformat every phone from (123)... to 123-..."), have you considered doing the phone number formatting as an auto-enter calc instead of a script?
19752, Wow, you're right. But the fact that FM seems to give only such a kludgy way to do it just begs for a simple script step to do the same thing, suspend auto enter while some maintenance is done.
Yeah, I keep hoping for this, too. Have you submitted it as a feature request? Remember that, to do the job properly, it has to be like what happens when you double-click on "If": It also automatically inserts an "EndIf" to "close the door" on the operation. Similarly, "DisableAutoUpdate" (to coin a term) should always be accompanied by a companion step to turn the auto-update feature back ON again after the script runs to completion.
and I think you can have another table in your database as utility table for "fixing" formatting etc and then re import as user19752 says meaning you can use all the formatting you need
I did make it a request. Yes, you would want it to be idiot proof and not leave Mod off. Maybe just an option in SetField to not trigger auto-mod-date or auto-mod-by?