Over 46,000+ Business Solution Developers Find answers, ask questions, and connect with our community of business solutions developers, business owners and partners.
We all have had the experience of encountering a FileMaker error message. The most common occurrence is when FileMaker tells you that it didn’t find any records that match your settings in a find command. Which isn’t so much an error as a condition message from FileMaker.
Some of the messages you get from FileMaker after an error might be confusing, particularly to the users that are not familiar with FileMaker. In particular, FileMakers default error message system does not know in what context the developer wrote the script. So it has no way to best customize the error message to make the best sense in the business logic used. That is where the developer can step in and lend a hand.
In the Control family of script steps, the Set Error Capture step is the fundamental first step that allows ScriptMaker to detect errors in advance and instead of showing a FileMaker error message … allows the developer run a set of script steps.
When Set Error Capture script step is included in a script and is set to the ON position, the FileMaker pop up error dialog boxes to the user are suppressed while the script is running. You then can use the IF, ELSE and END IF scripts steps are part of your error handling routine.
You can do a number of things when an error is detected such as return your own error message elaborating on the condition, run a set of subscripts that may resolve the problem and/or log the error condition for later illumination.
HOW IT IS USED
FileMaker, like almost any application, will give you an error message when an error occurs. Usually, this is a good thing and you can then go on about your business. Sometimes though, you would rather have the database react in a customized manner when a common error occurs. Usually the Set Error Capture step is used in conjunction with an IF Statement. If a particular error comes up, immediately perform a desired task. There are a number of reasons you want to do this but they usually fall into the two main categories of the user experience and automating processes.
The user experience is when you don’t want to confuse a database user with a FileMaker error dialog message they might not won’t understand. I’m not saying the FileMaker error messages are not top drawer ( because they are ). However, you might have some very inexperience users and messages about the found set might not make sense to them. Using error capture in your scripts gives the developer the opportunity to either rephrase the error message and even even create a set of script steps to resolve the error.
Automating processes is usually for tasks that run at midnight or without the direct over the shoulder attention of a database user. This allows the script to keep running or branch in another direction when these errors occur. If you didn’t have this step, FileMaker would basically be suspended until someone cleared the default FileMaker error message from the screen.
COOL IMPLEMENTATIONS OF IT
The FileMaker error message of “No Records Found” can toss a lot of beginning FileMaker users for a loop. If you trap for this error, you can control what the user can do after a search comes up fruitless.
You should always try to put this script step as close as possible to the top. It will not affect script steps that are above it in the script.
Got To Know Factor – 8