Compatibility: Version 6.8.x and 2003


Debugging code may be a frustrating experience. You wrote your code, everything looked right but when you run it in compiled or in interpreted, it does not work. In some specific cases, even tracing the code does not display any anomaly.

What is wrong?

When you trace your code step by step, 4D permits the retyping of a variable in the trace window and therefore hide a definite problem in the code. This type of code error can be seen very often when tracing web processes and when using undefined variables. The use of break points may prove more reliable, where the code executes with no Trace window and only stops when the break point is reached.

If something goes wrong when the database is run in compiled mode, the debugging options are limited since the debugger is not available in that mode. You can use a combination of alerts and beeps to know what code executes and to display the status or your variables; however using alerts may interfere with the operation of your database uses the events On Activate and On Deactivate.

The best debugging technique for a compiled database is to use a log file. You can create a process that generates a disk document and that uses the SEND PACKET command to append information how the code executes.

For example, if a method calls other methods, you may log some information such as current user, date and time, method name, and code (Begin/End/...) and log that information at the beginning of the method and at its the end. You may also log such information upon request, when a major error occurs or when a critical test fails.
This proves very useful, especially if you are running multiple processes and one of the processes crashes 4D. Information such as the process number, current user, table, record number, current method, etc. should help you narrowing down your problem to a specific process, method or command.