The Claris FileMaker Platform makes it easy for us to develop functional custom applications. We can move data from repeating fields and manage and customize images in FileMaker applications. It's also relatively easy for us to identify errors, but we have to know how to organize and interpret FileMaker error codes. If we learn when and how to leverage specific tools that FileMaker provides to troubleshoot bugs within our apps, we can avoid issues and frustrations down the line.
Identifying and capturing errors within our FileMaker applications are an essential part of the development process and it can feel a bit like a roller coaster ride. When we create an app that makes our jobs easier, we want to make sure that it does the right things effectively and reliably. That's why having a solid understanding of the potential error codes we might encounter and how to resolve them successfully is so important. In this post, we'll deal with the highs and lows of fool-proofing our FileMaker apps by maneuvering through conventional errors and exploring some common places where bugs tend to crop up.
Too often, after spending a ton of valuable time creating a scripted workflow for ourselves or our colleagues, we skimp on the testing and error capturing part of the development process. Instead, we speed through the task, delicately guiding our clicks and carefully preparing our data to give us perfect outcomes. We do this for the same reason that many folks close their eyes and grip the safety rail on a roller coaster. Errors and bugs frighten us because we don't want to be disappointed by our failures. We don't readily appreciate that "happy testing" doesn't squash bugs any more than closing our eyes makes the curves and dips of a coaster disappear.
We need to free ourselves of the shackles of fear and self-doubt. So what are some of the practical ways we can expose errors in our code? One way is to turn off Error Capture, at least initially. It's often hard to determine ahead of time what bugs our workflows are going to create. Instead of placing a Set Error Capture [On] at the beginning of each of our scripts, we can selectively add it to places where we've trapped for specific errors until we get a chance to step through the entire process. When users are testing the workflow to make sure it meets their expectations, any unexpected errors won't be hidden inside the script since that can silently mess up the data. It's nice when the errors are called out so that we can deal with them right then and there.
Another good tactic is to place the more challenging portions of our scripts, or even our entire script into a Single Pass Loop. It seems a little weird on the surface to use a loop function if we're not truly looping through a bunch of records, but this technique allows us to capture a bunch of errors and exit at the first sign of a problem. Also, it gives us one place to deal with the issues. A Single Pass Loop allows us to jump to a place in a script to handle the error. Think of it as a script step called "If This Then Go to Step [Insert Step Number]." This IFTTGS condition, if true, will take us to some other predetermined part of the script and start running from there.
vs.
The Single Pass Loop technique helps organize how we capture errors and then what actions we take when it comes time to resolve the issues. It also has the advantage of making our error trapping readily visible to anyone else who might edit the script in the future, including ourselves.
Now that we've laid out an overall framework for handling errors, we should take some time to call out some well-known twists and turns on the FileMaker scripting roller coaster track.
The peculiarities of the Go to Related Record script step trips up a lot of folks and there are different approaches to handling it. First, let's focus on the default "Match current record only" option. We need to see if there are any related records to go to and there are a few ways to do this. We can get a count of the related records using the IsEmpty function. Or, we can read an unstored calculation utility field in the child table with a Get( FoundCount ) function in it. Each of these methods ensures we're going to go somewhere. If we don't check this first, we might receive a "Record is missing" (101 error code) or "Layout cannot display the result" (414 error code). We have to be careful not to make other configuration missteps as well. For example, if we select a non-related table or incorrect layout by mistake, we could receive a "Relationship is missing" (103 error code). The key thing to remember here is that if we don't check for an error and we don't have any related records, we will not move from our current layout and found set.
Another wrinkle in the Go to Related Record step is that when we specify the "Match all records in current found set" option, we can get errors like "No records match the request" (error code 401) if all the records have no related records for any of the found set. We'll see "Record is missing" (error code 101) if the current record we're on doesn't have any related records, but others in the found set do.
Check out our blog post about the error logging script step and how it also helps us manage and troubleshoot problems. These are just a few ways to overcome some of the pitfalls we might experience on our FileMaker application development tracks. Next, we'll cover what to check before deleting records, opening and committing records, and creating new records. And this series would not be complete if we didn't discuss the common errors that come up when we're doing typical non-error actions, such as what happens at the end of looping through records. Stay tuned!
This article is also published on FileMakerProGurus.com.