Instead, we’re forced to evaluate every field on the record and compare the current field contents to the latest corresponding value in the audit history. The Get(ModifiedFields) function, unfortunately, doesn’t report the field modified with a Replace. However, when using the Replace Field Contents command, the performance impact can quickly become apparent with even relatively small found sets. The impact may not be noticed when editing a single record. Performance is always a concern when it comes to background processing and we’ve done what we could to minimize the overhead. Besides the direct effects of the simplification and reduced effort to implement, we also gained support for auditing changes in portal rows without scripting. The first of these goals provides two benefits. Capture changes made through the use of the Replace Field Contents command.Audit all repetitions of repeating fields.Remove the need for the New Record script included in the prior tip file.Our primary goals in revisiting this FileMaker audit trail technique were to: (Optional) Add excluded field names in a script that runs when the first window opens.Copy the _audit field and paste into each table of your app.Copy the four custom functions from this demo file and paste them into each file of your app.The steps to implement this revised FileMaker Pro audit trail technique in your own solution is as easy as:

The same principles are still going strong, and now we’ve added some bells and whistles based on user feedback. Nearly four years have passed since our last Easy-Bake FileMaker Pro Audit Trail made its Internet debut.

WordPress Repair and Troubleshooting ServicesįileMaker Pro Audit Trail “Revisited” By Doug West.

WordPress Maintenance & Support Packages.

See user history in filemaker pro 16