KNOWLEDGE BASE
Log In    |    Knowledge Base    |    4D Home
Tech Tip: How and When To Use Range Checking While Compiling
PRODUCT: 4D Compiler | VERSION: | PLATFORM: Mac & Win
Published On: February 9, 2001
Your current browser may not allow you to download the asset. We recommend Mozilla Firefox or Google Chrome.
Log In

Range checking can be an important part of the process of developing and debugging your databases. A prudent developer will always go through a development phase that includes range checking.

Diagnosing Errors:

Range checking is an especially valuable way to diagnose database flaws. Suppose you notice anomalies when running your databases. Before you start speculating about possible sources of these problems, remember the assistance that can be provided by the compiler with the Range Checking option.

Some potential anomalies are:


  • 4th Dimension displays its own error messages. If the error messages are too general, compile your database using the Range Checking option and retest your database. A more informative message from the compiler should be seen where the 4th Dimension originally displayed the more general error message.
  • Your compiled database does not perform exactly like your uncompiled database. Take a closer look at the warning messages. You may want to add the Range Checking option.
  • Your database performs smoothly in interpreted mode. After compilation, an error causes a system crash or a return to the Program Manager or Finder. By compiling with range checking turned on this tool can help you find the name of the method in which you crashed. Chances are good that your problem will be detected.

When to consider turning Range Checking off:

When you request range checking, certain areas of your compiled application may become slightly slower than they are without this option. The reason is that with Range Checking on, the compiled database checks before everything it does to see if what it is about to do will be valid, for example, not out of range. This is especially helpful as we have discussed above. However, then the database is no longer being changed, it is completely and thoroughly tested and no range check errors have occurred for a long period of time. You may want to squeeze those last few cycles out of the CPU. At this point you might consider turning off range checking to gain those last few cycles. But be forewarned, if in some obscure corner of your code you have missed an array reference or character reference that is out of range, when your end user hits that code they will make a quick trip to the operating system with no warning or clue to even help you guess what happened.

Just remember, if you have compiled your database with range checking off to get those last few cycles and your database crashes, don't call us. The bug is probably in your code.