by Daniel Smith

A modular open-source logging framework for FileMaker.


  • Logger module: Provide an interface for logging.
    • Call this module from any script you want to create a log entry from.
  • Log Writer modules: Save log data to a single destination.
    • Call Log Writers from the Logger module.
  • Log Viewer modules: View log data.
    • Provide a user interface for viewing log data.

File List

  • Log.fmp12: Main file for this project.
    • This file can be included with your current application to handle all your logging needs. It has been designed as both a self-standing logging application as well as an example file/documentation for the included Log-related modules.
  • LogWriters directory: Additional Log Writer modules.

Getting Started

Most documentation for this project exists in the READ ME scripts in the Log.fmp12 file:

  • File Module > READ ME
  • Modules > Logger > Logger: READ ME
  • Modules > Log Writer: FM > Log Writer: FM: READ ME
  • Modules > Log Viewer: FM > Log Viewer: FM: READ ME

Consider using additional LogWriters. View the READ ME scripts in each of those files if you choose to implement one.



View it on GitHub

3 responses to “Logger”

  1. Alec says:

    Just wanted to say that this is a great module. Exactly the functionality I need and very well-designed. I was able to quickly integrate into a complex, multi-file solution.

    My main alteration was to create the log records using SELECTOR-CONNECTOR. This works really well and in my case removes the need to manage commits, change layouts or open a new window.

    • Daniel Smith says:

      I’m glad you’ve found it useful!

      How did you integrate this in your multi-file solution? Did you add the Log Writer and Log Viewer modules to one of your own files, or did you keep the Log file separate?

      I’m asking because I’ve found that keeping the Log file separate provides the most value. For one, it is unlikely that you will ever be editing a record in the Log file while another script is creating a log entry. This means there is no concern about committing an open record, needing to change layouts, open new windows, etc. This is because the Log file opens to the correct layout for creating new records, and does not have any fields that can be edited on that layout. This is the reason I haven’t bothered to use SELECTOR-CONNECTOR to create log entries.

      Since you are creating records with SELECTOR-CONNECTOR, please be aware that you cannot create a related record if the current window has no records in the found set. I’m mentioning this because I often forget and it often comes back to bite me. Also, it means that, in some cases you do need to go to a new layout (one that you know has records in it, or that you can create a record if there isn’t one already).

  2. Alec says:

    So the solution I’m working on has some fairly strict rules in place, which has led to perhaps a slightly unconventional integration.

    1) The logging tables (Log and LogItem) are in their own file.

    2) The logging scripts and layouts for viewing the log are in the solution’s interface file.

    Thanks for the tip about not being able to create records with SELECTOR-CONNECTOR when there are no records in the current found set. I will need to allow for this in the logging script. As you can’t have an open record if there are no records in the found set I will probably just sneak to the CONNECTOR layout and back.

Leave a Reply

Your email address will not be published. Required fields are marked *