July 10, 2018 Appworks News Blog FileMaker 17 FileMaker Modules customizedFileMaker LoggingfmLogJSONlog historymodule Version 2.0 of fmLog – Free Download Imagine this scenario: At 4:47 p.m. Fred in sales opens the company’s FileMaker system and navigates to the contact list layout. He selects a contact and clicks a button to print a report of communications in the last three months. A beach ball icon spins for a few seconds, but nothing prints. Assuming something is wrong with the printer, Fred submits a ticket with the IT support desk and goes home for the day. The next morning, Carrie in marketing wants a list of contacts added to the database in the last month. She logs in and perform a find, but strangely, no contacts show up. She tries again a different way, but gets the same result. Manually scanning the contact table confirms her suspicion: the records are missing. She submits an urgent support ticket to have the most recent backup restored. As the developer of the database, you receive this request minutes later. Figuring out the root cause of the above scenario can be time consuming. If only a few users access the system, asking your coworkers about their recent activity could eventually triangulate a problem with the report button. But what if there are 50 users in multiple offices? Finding and squishing the bug becomes a daunting task. Unless you have logs. If database activity is tracked (record modifications, scripts, logins, etc.) determining root causes to scenarios like the one above becomes much easier. A log can potentially let you circumvent script debugging altogether by describing what occurred at a point in time and why. fmLog 2 is a free tool from AppWorks that can be added to any FileMaker solution. We include logging in every solution we build for customers, so fmLog had to be quick to implement, easy to maintain, and flexible enough to suit unique environments. It can be set up in four short steps and customized to log anything. Today we are announcing version 2.0 of fmLog as a free download. This version includes support for JSON, an option to “snapshot” records, Server-side operation (PSoS), and much more. It’s easy to implement, fast, and flexible. Snapshot records • Store a copy of every field name and value in a record as JSON • Enable simply by setting “snapshot” to true within fmLog’s script parameters • Extremely useful before deleting a record in a script Native JSON • All parameters for fmLog use JSON • As a result, fmLog 2 requires FileMaker Pro 16 or later • The entire log record is stored as JSON, so infinite types of log records and complexity can be stored in a single JSON text object • Use JSONGetElement () to get data for reporting Incredibly simple • No Plug-ins • Incorporates entirely into your database in two simple steps • Supports single or multi-file systems • Tested with FileMaker Pro 16, 17, FileMaker Go, and WebDirect • Improbably fast (nothing is impossibly fast) Feeling nerdy? Here is some sample code that calls log records. Just change a few simple parameters to implement these in your database: LOG A USER SIGN ON JSONSetElement ( “{}” ; [“log.id” ; get ( PersistentID ); JSONString] ; [“log.type” ; “login” ; JSONString] ; [“log.action” ; get ( UserName ) ” logged in at ” & get ( CurrentTime ) ; JSONString] ; [“log.user” ; get ( UserName ) ; JSONString] ; [“snapshot” ; false ; JSONString] ) LOG A RECORD VIEW JSONSetElement ( “{}” ; [“log.id” ; “123456789ABCDEFG” ; JSONString] ; [“log.type” ; “record view” ; JSONString] ; [“log.action” ; get( UserName ) ” viewed record at ” & get( CurrentTime ) ; JSONString] ; [“log.user” ; get ( UserName ) ; JSONString] ; [“snapshot” ; false ; JSONString] ) LOG A RECORD DELETION JSONSetElement ( “{}” ; [“log.id” ; “123456789ABCDEFG” ; JSONString] ; [“log.type” ; “record deleted” ; JSONString] ; [“log.action” ; “Record deleted at ” get( CurrentTime ) ; JSONString] ; [“log.user” ; get ( UserName ) ; JSONString] ; [“snapshot” ; true ; JSONString] ) By Matt Navarre
7 Comments Paul Jansen Posted on 6:45 AM - November 9, 2018 Thanks for sharing this log solution. I have one small observation. The PSOS test does not seem to be checking that the server is at least version 16 as the logging now uses the JSON functions. Shawn Posted on 9:28 AM - November 9, 2018 Thanks, Paul. We’ll look into adding this feature. Michael Posted on 6:57 PM - February 9, 2019 Hey guys you have done a great job! thank for sharing! Is ti possible to exclude some fields while saving the deleted record as Json (maybe by name or by type eg summary fields, calculation fields)? David Weiner Posted on 10:03 AM - February 11, 2019 Yes, actually! In the script called “Log – Save Record as JSON”, inside the lines that loop through every field, you can check for whatever field you’d like to leave out and have the loop restart before adding that field to the snapshot. You could use the “FieldType ( FileName ; FieldName ) function to leave out, say, summary fields or calculation fields, or even just use a hard-coded field name. Here’s an example calculation that will proceed to log a field if it’s NOT a summary field: Case ( PatternCount ( FieldType ( Get ( FileName ) ; $table & "::" & $field ) ; "summary" ) < 1 ; 1 ) Olly Posted on 9:07 AM - February 28, 2019 Thank for sharing this module AppWorks, very easy to implement. A method I’ve used to give me a list of ‘active’ fields i want to track (pretty much what your asking) is the following execute SQL “` // return a list of fields, excluding: summary, calculation and global fields ExecuteSQL ( “SELECT FieldName FROM FileMaker_Fields WHERE FieldClass = ‘Normal’ AND FieldType NOT LIKE ‘global%'” ;”” ;””) “` Ameenullah Smi Posted on 9:07 AM - April 8, 2019 Hi I am unable to find the download link. Eleanor Fulton Posted on 9:30 AM - April 8, 2019 https://app.works/product/fmlog-2-0/