To order Alpha Four or Alpha Five, click above to go directly to Alpha, or call 800.451.1018 or 781.229.4500

             
Alpha Newsletter

Saturday, June 1, 2002 Issue 4   VOLUME 1 ISSUE 4  
HOME
TOPICS
News & Notes
Learn Alpha Five
Tips & Tricks
Tech Corner
Developer Spotlight
CONTENTS
Alpha Five v5 Preview
Alpha Five Web Application Server is Coming!!
Alpha Four to Alpha Five - Chapter 4
An Interview with Chris Barbariantz
Create a Template for Forms and Reports
Trouble-Shooting Made Easy (well, easier anyway)
Make Operations Faster
Auto-Increment Script - IMPROVED
Windows Advantages of Alpha Five
Naming Conventions
Alpha Four Short-Cuts
Different Uses of Alpha Five
T E S T
Trouble-Shooting Made Easy (well, easier anyway)
TC034
by Bill Warner

Troubleshooting

Have you ever had a problem with a program or computer?  (That's sort of like asking, "Have you ever had a cold?" isn't it??)  Well, it can happen to the best of us (and the worst of us, and ...).  Here are some trouble-shooting procedures, contributed by several of our "experts1," that you can follow.   These apply not only to Alpha, but to general computer problems as well.  Please note:  This is by no means meant to be a complete list, and we welcome any other suggestions you might have.

I'll try to put this in order, so that the easiest procedures are first.  Keep in mind that this can vary tremendously, depending on the problem.  Hopefully, it will serve as a useful guideline.

WHAT'S HAPPENING (or, more to the point, why is it happening)??

Probably the most important aspect of resolving a problem is identifying the problem.  While this might seem somewhat obvious at first, it is not always evident what is causing the problem (the symptoms are usually very obvious).  For example, the program crashes when you try to do something.  Let's use this as a starting point, and come up with a list of questions:

1. 

Did you make a change in the program just before the crash, such as adding a script or expression?

2. 

Did you install another program that might be conflicting with Alpha?

3. 

Can you reproduce the crash?

4. 

If the program is on a network, do other machines crash as well?


As a way to answer these questions, here are some steps to take, which are good for resolving computer problems in general.  Sometimes these simple steps will solve your problem:

1. 

Close Alpha and reopen it.  If the problem persists --

2. 

Close all programs, and reboot the computer (you'd be amazed at how many problems rebooting can solve!).  If the problem persists --

3. 

Check your system resources before opening any programs.  If the resources are below 80%, your computer is starting way too many programs when it boots.   Remove these programs (here's how) and reboot.

4. 

If you have another computer available, try the same thing on that machine.  If the problem goes away, it's likely there is a problem with the first one.

5. 

Network computers are often signed off, but not re-booted.  Every computer in the network should be re-booted every 3-4 days as a minimum, because a lot of resources remain in use, even after the corresponding software is closed.


If the problem is still there, it's probably in the program.  But there are still some simple steps you can take before hanging your self (or deep-sixing the computer):

FORMS, BROWSES
 

Try to duplicate the problem using the default form or browse.  If the default works, then the problem is in the form or browse.

 

Check the field rules for the table.  If the program was working, and you added a field rule, that's a good place to start.

 

Make sure the indexes have been updated recently.  


EXPRESSIONS
 

When a long expression returns an error, copy it to Word Pad or other word processor (so you don't lose it), and then remove all but the first part, and evaluate it.  Then keep adding segments until you get to the part that causes the error.

 

If it doesn't cause an error, but evaluates incorrectly, there could be a nested IF that is evaluating in the wrong sequence.


SCRIPTS
 

Click on Check Syntax in the Script editor.  This will find many (but not all) problems.  Note:  A script with syntax errors that is run from a button will not always show an error.  It will fail to run at the point of the error.

 

Try breaking the script into small segments, and test each segment separately.

 

Put a ui_msg_box in various places in the script, to see if certain parts are being executed, or it values are being calculated properly.

 

You can create a global function that calls trace.show(), using either a flag to indicate position in the script, or a variable value as argument to the function.  The trace window is shown and data displayed, to find out where the failure is occurring when a number of scripts are involved.

 

You can also use trace.writeln() to display what's happening in the trace window.

 

Use statusbar.text() to display progress in a script.  By putting a message before and after an operation, you can visually tell that it has completed.  E.g. "Starting ZIP operation in DOS Box", "Zip operation complete."

 

Use debug() at various points to turn debug on and off.

 

Use F4 to compile the code and make sure there are no compile errors.

 

Shut down A5Halt and any A5's left over by pressing Ctrl-Alt-Del.

 

Often, it's good to just walk away for a while.  Sometimes you're too close to the forest to see the trees.


DODGE THAT BULLET!

Probably the simplest way to avoid problems in the first place is to avoid doing things that could give you trouble.  Here are some things that can cause problems:

 

Spaces in object field, index, layout) names, or names that are too long (see Naming Conventions in this issue for more info).

 

Forgetting to close a dialog.  This is a little trickier than it might seem, because having a button on the dialog to close it does not close it completely.  You also have to close it from the script that calls it.   Here's an example.

 

Evaluating a numeric field that is blank.  If you try to retrieve the field's value from a form by using a script (which then uses the value as a condition in another part of the script), and the field is blank, you won't get what you want.  Instead of evaluating to zero, it can sometimes evaluate to a number that is about 25 digits long.  Aside from being incorrect, it can also crash Alpha.  Note that this is not true if you use the table mode in your script.

 

If you use field rules or functions that use an index (such as table lookups, LOOKUPC, DBSUM, etc.), and you change an index's name, any functions that used the old name will no longer work properly.

 

If you try using two *ANY functions with an .AND., you'll get an error (this function is a hold-over from Alpha Four). Use CHAR_STRING$CHAR_EXP2 instead.


While these procedures won't solve every problem, they should help you identify a problem more easily, so it's easier to fix.  And, if worse comes to worse, don't forget about the Alpha Message Board.  Chances are, someone can help with a solution or work-around.


1 Many thanks for suggestions from:

   Ira Perlow
   Tom Lyon
   Cal Locklin
   Peter Wayne
   Craig Schumacker

2 In this expression, CHAR_STRING is a string that is included in CHAR_EXP.  For example, to find CD in the string ABCDE:

"CD"$"ABCDE"

Another example; Find the variable NUM in the JOB field:

VAR->NUM$SALES->JOB

This is a logical expression; it returns TRUE or FALSE.
[PRINTER FRIENDLY VERSION]
Powered by iMakeNews.com