FMPerception Saved My Butt


It happens. You’re moving quickly, jammin’ on your favorite FileMaker custom app. Laying down some insane custom business logic in the form of one awesome, totally badass FileMaker Script. Then you notice that other script. The one you need to get rid of. No time like the present. So you pop over to it, hit “delete”, crush the popup confirmation before you have time to read it and… Whoops, something went very wrong!


You deleted the wrong script.  Your awesome, badass script with the insane logic is nothing but a memory. There is no undo. It’s gone. It’s not in the backup because you were just working on it.  It’s too new.  You are totally f#%@ed! You weep, you rage, you even try mediation. Nothing works. The script is still gone.

Then you remember. “Wait I just made a fresh DDR for FMPerception“. A smile creeps across your face. Yeah, you’re gonna be OK.  FMPerception is going to save your butt.

True Story

The above scenario happened to me this week. I deleted the wrong script. For a moment, it was bad. But then I remembered that FMPerception had the script. I could easily restore it, and reconnect it the other scripts that were using it. Just 2 minutes later I was done.

Phew!  Watch the video above for exactly how to recover a deleted script using FMPerception.

Need For Speed

FMPerception is so fast that it doesn’t get in the way of your workflow. As a result, you’ll use it all the time. You will be much more likely to have a recent analysis than if you are using an analysis tool that forces you to wait minutes or hours. Most FMPerception users know all about that, but what they might not know is that your analysis is also a backup, and can be used to restore code that you deleted or broken. And that can save your butt!



FileMaker Testing, Part 1 – Your First Test


With the release of FileMaker 16 and native JSON functions, the ability to create a testable solution has been vastly improved. In this blog post, I will walk you through a simple example of what testing is, and how it can improve your solutions. Most developers have had situations where they need to alter some existing logic, and are concerned that they might alter something with unforeseen consequences. Wouldn’t it be nice if you could ensure that your changes didn’t break existing code? Welcome to FileMaker Testing.

Automated Software Testing

Software testing has a lot of different variations and buzzwords associated with it. You’ll hear all sorts of phrases and acronyms thrown about like TDD, BDD, Unit Testing, Regression Testing, etc. It’s worth a learning a little something about these at some point. But at the heart of all of them is a simple concept; write some code to automatically test some other code.  If you do, your code will be less fragile, and easier to maintain.

What is FileMaker Testing?

A test is a FileMaker just script used to ensure that other scripts are working properly. Tests ensure that scripts are not only accomplishing their goal but also producing the desired result when they fail. While there are many ways to perform FileMaker testing, we test using the following assumptions:

  1. Each script to be tested accepts & returns JSON as a parameter
  2. We will be using custom functions for handling errors, testing JSON objects, and validating a JSON payload

Writing Testable Scripts

To prepare your script that needs to be tested, it should always return JSON to the script that called it. This means that if the script fails, it should return an error JSON object. If it succeeds, it should return an object representing the data that was changed. See the example script called “Create a Project” in FileToTest. You will notice that it returns verbose errors on all failures, and returns a JSON object when successful.

Writing The Test Script

To prepare your test script, you need to do three things in karbon_tester:

  1. Create a JSON Object to pass the script using the layout “Edit Test Data”
  2. Create a script in the Folder “Project Testing” (Copy the existing scripts…you’ll get the idea!)
  3. Add the script you created to the script “Test – Project”

Do We Test Every Script?

There is no reason to test each & every script. We only write tests for those scripts that play a critical role in the solution. Once you are comfortable with testing, it will become clear what you should test. It’s up to you.

Benefits of FileMaker Testing

The benefits of creating test scripts are compelling. First, it provides any solution with a level of stability that is difficult to achieve in a timely fashion. If multiple developers are collaborating on the same solution, the test file enables everyone to run common tests on core business logic, and see if they have produced any unforeseen fatal errors.

Second, it provides a level of clarity for you, the developer. Once you begin writing tests, you will take on an alternate persona, where you are actively poking holes in your own code. This may seem like a small difference, but we believe you’ll be surprised once you try it. You become much more critical, which improves your focus & clarity.

Third, the readability of your code will improve. One thing that makes JSON difficult to handle is that there is not a repository for JSON objects within a FileMaker solution. When a script is designed to handle records in multiple tables, karbon_tester serves as a clear, contextual example of how to create & pass JSON objects to work within a solution.

Is it Worth It?

The first question many people seem to ask when introduced to testing is “is this worth it?” Our answer would be that it depends on the solution. If you have a complex system, multiple developers, and a need for stable solutions, it’s not just worth it, it should be the standard.


To start, download our sample files here. Open “FileToTest”, and create a project. Review the script “Create a Project” to see how the file works. Then open the file “Karbon_Tester” and run the existing test. See how easy that was? Now you should create your own scripts to test creating a status.

What About Editing Data & Managing Test Data?

We will be releasing part 2 in this series in the future. We will walk through options for loading test data, & managing records that are used only for testing. The testing in this sample is intentionally simple to grasp and does not confront some of the nuanced issues involved in testing.

What about Karbon?

We know some have you have been waiting for us to release some of internal tools and frameworks that we group under something we call “Karbon”.  This is the piece piece of that puzzle.  More coming soon.

Looping Through and Filtering Lists with FileMaker

Looping through and filtering lists of values turns out to be a common task in FileMaker.  Having a few different techniques at your disposal is quite useful. In this post, we are going to look at a set of related techniques for processing lists.  First we look at how to loop through each item and perform some function or task on each item.  Then we will move on to a custom function for filtering lists by any valid FileMaker expression.  Finally we will use another Custom Function to easily parse Layout Object Names from a layout and use them in a dynamic slide navigation scheme.

Read more

What Does GetField(fieldName) Return?

FileMaker’s GetField() function has always been struck me as a curious beast.  Every since it’s release back in Filemaker 5.5 or there abouts I had assumed that it returned the contents of the field specified by the parameter.  But there were a couple of cases where it didn’t work that way and I’d get fooled every once in while.  I didn’t quite understand what was going on.  I think I finally stumbled on an easy way to keep it straight. Read more

Unit Testing in FileMaker


Unit Testing is the practice of  testing individual chunks of code to make sure they are working as designed.  Ideally it is done with a single click of a button, so that you can do it all the time.  Traditional FileMaker coding doesn’t lend itself to this practice very well.  It’s just too tightly coupled.  But if you take some time to organize your code in a modular way you can start to incorporate something like Unit Tests into your development practice.

First you need to separate out the logic you want to test into well factored API like scripts.  These can take parameters and they usually return a result.  The main point is that you give these scripts the power to do what the need to do to your database, and you make sure that they report back if they fail or not.

Once you have your API scripts laid out you can the write yourself a bunch of test scripts that exercise those API script and make sure they are doing their job.  I put my Unit Tests in a separate file so I don’t clutter up my deliverable files. Then as I go along writing code, I periodically go back and run all the scripts. When I do something that cause my tests to fail, I can see it right away.  I know what test broke and hopefully I get some kind of error that might help tell me how it broke. From there, its relatively easy to go about fixing the code.

Here is a movie that shows what that ends up looking like.