Turning on Set Error Capture can remove an inconvenient dialog, but it does not fix the operation that failed. A useful script tells the caller what happened and avoids continuing as though a missing record had been found.
This example uses a prepared find request in a practice file. It only finds records and returns text; it does not edit them. The script steps shown are available in current FileMaker Pro. Build and review the flow in a working copy before connecting it to a real button.
1. Define three outcomes.
For a search, three outcomes are enough to start: records found, no records found, and an unexpected error. “No records found” may be a normal business result. An inaccessible file or invalid operation needs a different response.
Example result contract
found
not_found
error:<FileMaker error number>The caller should recognize these values deliberately. In a larger solution, you might return a JSON object with separate status, code and message keys. Keep the contract consistent across callers instead of returning a mix of record IDs, dialogs and empty strings with undocumented meanings.
2. Capture the result before another step replaces it.
Script reading guide: recreate these steps in Script Workspace. This is not a pasteable native script.
FileMaker script
Set Error Capture [ On ]
Perform Find [ ]
Set Variable [ $findError ; Value: Get ( LastError ) ]
If [ $findError = 401 ]
Exit Script [ Text Result: "not_found" ]
Else If [ $findError ≠ 0 ]
Exit Script [ Text Result: "error:" & $findError ]
End If
Exit Script [ Text Result: "found" ]Start this teaching fragment with a valid find request already prepared in Find mode. It is not a complete search button. In a finished script, verify layout navigation, mode changes and criteria setup as well. A failed setup step must not be followed by a find against unintended criteria.
Capturing Get ( LastError ) immediately preserves the error from Perform Find. Test the saved variable afterward. A successful intervening step can otherwise replace the error you meant to inspect.
3. Let the caller decide what the user sees.
Immediately after Perform Script, the caller can save Get ( ScriptResult ) and choose its next action. For found, show the results. For not_found, keep the search understandable and offer an edit or clear action. For error, stop the dependent workflow and give a useful message.
Do not silently show all records when a constrained search fails, especially if the next action is an export or batch update. The visible list could look reasonable while representing a completely different group of records.
A reusable worker script can return an outcome without opening a dialog. A desktop button script can then decide how to present it. Server-side work needs an outcome that can be inspected without someone watching a screen.
4. Check the operation that matters.
Finding a record successfully does not prove a later edit was saved. If the workflow goes on to write data, inspect errors at the write and commit points too. A record lock or validation rule can prevent the intended change even though the search succeeded.
Before adding writes, describe what the user should see when the record is locked, when validation fails, or when their privileges do not permit the action. Do not retry in a tight loop or bypass validation simply to make an error disappear. The recovery belongs to the business workflow.
For a diagnostic log, begin with the script name, step or operation label, error code and time. Avoid logging full customer records or credentials as a shortcut to understanding the failure.
5. Test each branch on purpose.
- A valid request matching a practice record: expect found.
- A valid request matching nothing: expect not_found.
- A find with no criteria: expect an error result, not found.
- A caller that runs another script: capture the first result before it is replaced.
Use a script review to locate every caller before changing the returned contract. DDR Explorer can help inspect references in an exported report; it does not run the script or prove that every dynamic call is represented.
The goal is not an error-free-looking screen. It is a workflow that stops at the right point, preserves a useful explanation and lets the user recover without guessing what was saved.
PUT IT INTO PRACTICE
Continue with Filesoft.
Open the DDR Explorer guidePrefer a guided learning path? Explore the free FileMaker courses.
Continue reading
Claris references: Set Error Capture · Get ( LastError ) · Get ( ScriptResult ) · FileMaker error codes. Examples are learning aids; verify them in your own FileMaker working copy.