Launch Files

Troubleshooting

Unpredictable Global Default Values

I have global fields, used for holding system settings, that have been working perfectly for weeks, but today suddenly they have different data in them. What happened?

It's likely they got reset by some script modification you've recently made, or when you had files in an offline, single-user state. In our practice, we find it difficult to remember to set globals for default states in single-user mode through the course of developing and maintaining a system. This is a common source of bugs and we've found over the years not to make any assumptions about global values; it's better to simply set them explicitly within a startup script. It's also important to either explicitly set or test for values at the beginning of a script that depends on them.

Use Re-Login for Testing Access and Sessions

One of my users is reporting a problem that I don't see when I'm logged in. I'm getting sick of having to re-login time and again to test this. Is there an easier way to test this?

If you're having trouble testing how other users, with different access levels, might be interacting with your system, write a re-login script that enables you to hop into another account at the click of your mouse. It's even possible to store passwords when using the Re-Login step. Connect it to a convenient button or place it in the Scripts menu and you have one-click account switching.

Another approach might be to create a "debugging" custom menu (with the various login scripts available) and disable the menu before deploying the system.

Making Sure That Your Auto-Entry Always Edits

My auto-entry function worked the first time I edited a field, but then it remains stuck and won't update again. What setting is the likely culprit?

If your auto-entry field for your audit log isn't updatingit does it once, but then never againmake sure that you uncheck the Do Not Replace Existing Value for Field (If Any) option. It is always checked by default and is easy to miss.

Likewise, the Audit Log routine we described depends on there being data in the field to begin with. Either seed it with something (we use Creation TimeStamp) or turn off the Do Not Evaluate If All Referenced Fields Are Empty option. It too is enabled by default.

Trapping for Errors

I need to tighten my scripts, and don't want to have to code for every exception under the sun. What's the best approach for trapping for errors?

Trapping for errors is always a smart development practice. Get into the habit and you'll save yourself years of your life debugging. A simple approach is to simply use the Get(LastError) function and use a Case or If / If Else routine to display meaningful messages and logic branches to your users. You can trap for either explicit errors or just a nonzero number.

A better way to abstract your code and provide yourself with a central place to reuse error handling is to simply write an error routine once and be done with it.

There are two ways to manage error messaging. You can either set up your own errorCodes table or build a custom function. Setting up a table is simple and allows you to add your own custom error conditions and messages. You can do this as well with a custom function. The idea is simple: Establish a global gError field in your main system and relate that to an errorID in your error table. You can also use a $$error global variable and have a custom function reference it.