Easy to Generate Debugging Reports

Introduction

How many times do users let you know of a bug in their solution and yet are unable to provide any detail about what they were doing at the time? What layout were they on? What was the found count? Were any plugins installed? What record were they on?

These are very common questions the developer may ask and yet not receive a good answer to.

So how do we find the answers?

Well sometimes good users can provide us with the answers but more often than not they simply aren't paying attention to the state of the solution at the time a bug occurs - which is fair enough. As a developer maybe we can just build some tools to provide us with the answers the user cannot.

We did just that by building a debugging report script that will collate information into a JSON object that the developer can then do with whatever they please.

It combines three useful sets of data in JSON format:

• All field values from the users current record (or any nominated record)
• Results of every Get function
• Any other developer specified data which may be of use (e.g. globals, variables, session state..)

This is a single script that can be initiated from anywhere. The JSON is returned as the script result.

Getting record values

To get all record values, one might use the Execute FileMaker data API script step, combined with a pre-build layout in order to return this information, but who has time to manage layouts! We wanted a way to do this all within a script and so we utilise FileMakers internal SQL tables FileMaker_Tables and FileMaker_Fields to give us all the information we need.

Andrew Duncan from Databuzz has an awesome article on these tables which I refer back to constantly, I strongly encourage you to check out his article here.

In fact we actually featured this technique in our top 5 of 2021 article just recently - check out that article for more detail here!

In short, the process for obtaining the record data is as follows:

1. Obtain a reference to the records primary key field
2. Extract the table occurrence name, and field name
3. Use the FileMaker_Fields table to obtain every field name, class and type from that table
4. Loop through the field data, excluding items you do not wish to debug
5. Build a query to obtain just the field values you do wish to debug
6. Loop through the results, generating JSON

This is clearly documented and laid out in the script in the example file.

Getting Get Values

The Get functions (e.g. Get ( FoundCount )) are invaluable in the information they can provide the developer about the state the solution was in when an issue occurred for the user. Some of the more useful functions include:

• Layout Name
• Window Mode
• Installed Plugins
• Found count
• Record lock states
• Window Names
• and more..

They are very quick to calculate and so why pick and choose - just evaluate the whole lot!

The script stores a list of every get function in a variable. We then simply loop through, and build up JSON using ithe function name as the key. The value is simply determined by running the function through the Evaluate function - so simple!

Getting other data

Get values, and record values are all fine and good but often the important information about the users session is kept in things such as global variables and fields. Structures that help store information about the user and what they are doing. For example some systems maintain session information in a table, and so it would be useful to know the ID of that session record. Others maintain a user table and so knowing the user ID could be beneficial. Other things too such as the users current position in a wizard, or tab in a layout can be logged providing that information is being tracked by the developer.

Our debugging script has a section just for this type of information and given the custom nature of the data, needs to be set up by the developer for each specific solution it is used in.

Putting it all together

Our debug report script takes two parameters:

• A reference to the primary key field (for record value collection)
• A type of data to collate - record, function, other (or all/blank for everything)

JSON is simply outputted from the script.

That's obviously not the end of the story. It's then up to the developer to make use of the reports and obtain them. One option may be to email the developer the report, another might be to store the report within the solution in a debug table.  Our preference is both of these! We both store the reports and email them to the developer each time one is submitted. Often times the debug report is a prompt to follow up with the user about the issue more.

In our example file we opt for the storage mechanism only to illustrate how it can work - you kind of get the idea about what would happen with email!

The Benefits

This tool has already paid for itself for the time it took to develop. It has been used at least a dozen times and every time has really helped narrow down circumstances around a bug and has helped me as a developer replicate the same conditions the user would have experienced at the time.

Example File

No FileMaker Weetbicks article is complete without an example file and so here it is - click here to download the example file!