Terminate Bugs with Helldiver-Level Precision Using Hidden Gems in the JD Edwards E1 ER Debugger

Tools:9.2.7.3

Killing bugs is fun in Helldivers II but it does not feel the same way when you're hunting for bugs in your ER logic. If you're a JD Edwards E1 Techie, chances are you use the ER Debugger almost every day to troubleshoot applications and reports. But there’s a small feature hiding in plain sight that can make debugging much cleaner and faster.

Lets take a quick look at it.

A Typical Debugging Situation

Imagine you’re debugging a report that processes thousands of records. Multiple orders having multiple companies, amounts, and what not.

Now lets say you want to check the amounts for a specific company, say Company 00720.

A common approach is to write an IF condition that checks for the company value and then place a breakpoint inside that condition so the debugger stops only when the condition is satisfied. Though it works, it also means adding and reverting code just for debugging.

But what if you could achieve the same behavior without modifying the code at all?

Breakpoint Properties

While debugging, ever wandered into the Breakpoint Properties ?

You can access it by right-clicking on a breakpoint in the ER debugger and selecting Breakpoint Properties.

Inside this window, you’ll find two options:

• Condition
• Hit Count

Condition

The Condition option allows you to define a simple expression. The breakpoint will only trigger when the condition evaluates to TRUE. Below is the syntax:

<variable_name> <operator> <value>        

Using our earlier example, if you want the debugger to stop only when Company = 00720, you can define a condition like:

You can verify the expression by clicking "Validate Condition". Strings, Dates and Characters should be enclosed with in quotes.

If you need assistance with the syntax, the "Help" button provides guidance on writing valid expressions.

Hit Count

The Hit Count option is particularly useful when debugging While loops.

Instead of stopping every time the breakpoint is reached, you can configure the debugger to pause only after the breakpoint has been hit a specific number of times.

Choose the desired execution option and enter the hit count value.

The window also displays how many times the breakpoint has already been hit during execution, making it easier to track progress.

These features allow you to debug more efficiently without modifying your code, keeping your logic clean while still enabling precise debugging.

If you haven’t explored Breakpoint Properties in the ER Debugger yet, it’s definitely worth trying the next time you troubleshoot a report or application.

Armed with these features, you can now exterminate bugs with absolute precision!

Sometimes the most useful tools are the ones already built in and just waiting to be discovered.

See you on the next post!