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] )