Building robust error logs in FileMaker 11

Writing the Write to Error Log Script

Wrapping up, we’re going to build a Write to Error Log script. This is the script that will trigger when something goes off the rail. It will trap a couple of last-minute error items, open a new window and bring up the error log layout, then write a new line to the error log and close the window. This script will have to run as full access privileges because we want to make sure that everyone has the ability to report error logs, even if they are read-only. A new window is used because it preserves the previous state and also allows things like validation errors to be written.

I’m fond of return-delimited script parameters, but if you use the AssignParameters and GetParameters custom functions, you can obviously refit your solution to use those functions instead. But I’ve found that cramming multiline parameters into a single parameter is pretty easy by swapping out custom escape characters using the substitute function.

The Write Error Log Script

The Write Error Log Script

The resetting of $$_err_baserecordprimarykey is similar to what was done in a custom function previously. If your error happened on a different record, this will make sure that the base record was trapped, as well as the record that triggered the error.

// If we're on a different Primary Key than we started with, trap that primary key as well.
$$_err_baserecordprimarykey &
If(GetPrimaryKey ≠ $$_err_baserecordprimarykey;
" -->" & GetPrimaryKey)

This is all we need on this script. Whenever it is called, it will write its error log and finish up.
The only thing left to do is make sure that our template script has a basic error reporting module added to it that can be copied-and-pasted throughout the scripting process.

Updating the Template Script

Now we want to add an Error Trapping section to the template script. This section of code should be copied-and-pasted throughout a script liberally to give you an idea of where in the script the error occurred, and may be modified to suit your needs for a given script.

The only bit that needs to remain static is the actual call to the Write Error Log script and the variable car directly after the IF statement to trap the Error Number (make sure you don’t put anything in front of that because it may clear out the LastError value. The Parameters are as such:

Get(ScriptName) & ¶ &
Substitute(Get(ScriptParameter); ¶; "|*|") & ¶ &
$ERRLOG_errornumber & ¶ &
Substitute($ERRLOG_errordetails; ¶; "|*|") & ¶ &
ErrorSystemState

This sends along any last-minute bits that the error log will need.
The first section of the Error trapping section is a simple IF statement to test to see if there’s been an error. This may be as simple as testing if Get(LastError) > 0 (you may want to make this 0 a 1 if you are allowing a user to cancel a process). You may want to substitute different flavors of Get() statement depending on the preceding script step you’re testing for. For example:

  • Get(FoundCount) = 0 or Get(LastError) = 401 if you’ve just done a find.
  • Get(LayoutTableName) =/= [expected layout table name] if you’ve just performed a Go To Related Records step.
  • Get(LayoutAccess) = 0 if you’ve just changed layouts
  • Get(RecordAccess) = 0 if you’ve just changed layouts and are about to write records. This is a pretty good shorthand for figuring out if your limited record level locking is going to work on a record.

After the If test, we update the $$ERRLOG_errordetails variable to provide a description of where the script went off the rails. For example, if your Go To Related Record from Job to Project failed, you can make that value “Unable to go to Project records for this Job.” Obviously, if you don’t put Details in, you’re not going to have any easier time troubleshooting your errors.

After writing the error log, there are some simple “graceful exit” items that may be used, removed, or modified as needed: You may choose to simply set the $scriptResult to exit with an Error code, or you may wish to reset the user and halt the script. Depending on how you construct your scripts or your specific needs, you may want to change up which items are enabled or disabled.

For examples of the Error Trapping System in action, see the 2 – Error Log ExamplesSample File.

Note, this file is password protected. There are two accounts, Admin (no password), and user / password.

 
Pages: 1 2 3 4 5

1 Response to “Building robust error logs in FileMaker 11”


Leave a Reply