ADAPL is Adlib's proprietary programming language. We use it to write additional functionality which is too application-specific to program it into adlwin.exe (on which most Adlib applications run). This additional functionality is constructed in small programs called adapls. The source code is stored in .ada files. You can edit these files in simple text editors like Windows NotePad, TextPad (offers line numbering), Axiell Designer or the ADAPL Debugger. After changing the source code, you'll have to recompile it. You can do this from a DOS command prompt, from within Axiell Designer or from within the ADAPL Debugger. Compiled adapls have the .bin extension. Adapls can be linked to an Adlib application or database in several ways, so that they will be executed automatically after leaving a certain field or screen, or before a record is stored or when printing records. Adapls are usually stored in either the \adapls, \adapl sources, \adaplbin subfolders, or in subfolders with the name of your application, in your Adlib system folder.
For more information about the ADAPL programming language, see the Axiell Designer Help.

The ADAPL Debugger provides a programmer-friendly way to debug adapls. Any software program can fail in many ways, and so can adapls. Let's divide software bugs into two categories for the moment: syntax errors and functional errors. Syntax errors include typos, forgotten separation characters like brackets or commas, incorrectly spelled variables and commands, etc. These syntax errors will usually come up during compilation of the adapl: compilation will fail and the compiler displays a message stating the line number* of the syntax error. You'll have to edit your adapl, search the relevant line for the syntax error, correct it, save the changes and try to recompile the adapl. The ADAPL debugger cannot help you find these syntax errors.
Only after compilation is successful, and functional errors appear when running the program (the adapl is not doing what it's supposed to do), the ADAPL debugger can help you find the problem. Basically, you'll have to recompile your adapl with the debug parameter -d, and next time this adapl is executed in your application, the ADAPL Debugger opens. In it you'll be able to continue executing the adapl line by line, jump to a certain line, or skip subroutines. And all the time you'll have a wealth of status information at your disposal: this includes the present value of all local and system variables plus the contents of all opened local and FACS records. This way you can find the exact spot where a variable assumes the wrong value, where a loop isn't being run through as you expected, where the wrong FACS record is retrieved, or where the adapl freezes or crashes, for example. Knowing where to look, is of course half the solution, and it'll save you a lot of time fixing the bug.
The ADAPL Debugger also works for import adapls, but only if you run an import job with import.exe; you cannot debug an import adapl if you run the import from within Axiell Designer.

* Line numbers are not exact in ADAPL, unfortunately. Also search the two lines above the indicated number for the syntax error.