Here are methods you can use to debug code. We use @Prompt([Ok]) for debugging fields and macros. It can be used
to show you the value of a field before and after a function is performed. a := "1234"; @Prompt([Ok];"Debug- a";a); b := @Left(a;2); @Prompt([Ok];"Debug- b";b); If your not sure where the error is occurring within a formula you can use @Prompt to set breakpoints. @Prompt([Ok];"Debug";"Breakpoint 1"); some code... @Prompt([Ok];"Debug";"Breakpoint 2"); some more code... @Prompt([Ok];"Debug";"Breakpoint 3"); @Prompt will only return a single text value. Therefore if you need to examine a timestamp or number they need to be converted to text first. If you need to examine a list turn it into a single value with @Implode. When creating macros, we like to test major parts in field formulas within forms. It's much easier to see the results of a DBLookup in a form than to try to display it from within a macro. This also reduces damage to documents from bad macro code. When debugging a background macro on the server we replace @Prompt with @Mailsend. We just send a memo to ourself with the values we need to examine. Background macros can also be tested on a workstation but a macro may work on a workstation then blow up on the server. The reason is usually access. When running a background macro, the server limits itself as if it were a user on the network. If it doesn't have access to views used in lookups the lookups will fail. Of course, the lookups worked for you because you have access to those views. Making sure the server has access can avoid many bugs relating to security.