Hosted by Chandra Wobschall and Paul Houtkooper

Hey JDE Connection listeners, Chandra and Paul here! We’re back, recovering from another marathon and questioning some of our life choices. Apparently, running 26.2 miles with a sore hamstring isn’t quite enough punishment, because this week we’re tackling another potentially painful subject: SQL updates in JD Edwards.

We all know the temptation. The business needs thousands of records updated, time is tight, and SQL seems like the quickest way to get it done. We’ve certainly been there. But as we discussed this week, sometimes that shortcut comes with a price tag nobody wants to pay.

When a Quick Fix Becomes a Big Problem

We kicked things off with a real-world example involving a SQL insert into the chart of accounts that didn’t go quite as planned. A mismatch in company information created exactly the kind of headache that makes us cringe when someone suggests updating the database directly.

The frustrating part? JD Edwards already had a way to catch the mistake. By going straight to the database, we bypassed the very validations designed to protect our data.

We understand why organizations rely on SQL. Sometimes the business needs 9,000 records updated yesterday, and nobody is volunteering to do them individually. But how often do we consider everything happening behind the scenes when we make those changes?

Finding a Better Way, With a Little Help From AI

Fortunately, our conversation took a more encouraging turn when we shared a recent experiment with Claude Code and JD Edwards Orchestrator.

Faced with another large-scale update requirement, we decided to see whether AI could help build an orchestration that would handle the work through the existing JD Edwards application. The goal was simple: make the updates efficiently while preserving the system’s built-in validations.

And guess what? It worked!

There was some setup involved, of course, but the result was a reusable approach that could check existing values before making changes. We even got a little impromptu requirements gathering from Paul along the way. Apparently, some habits are hard to break.

The experience sparked a great discussion about how AI tools are making capabilities like Orchestrator more accessible. For those of us who have relied on SQL because building an alternative seemed too time-consuming, that opens up some interesting possibilities.

If We Keep Working Around It, Who Knows It’s Broken?

One point to keep in mind is the importance of sharing these challenges with Oracle and the broader JD Edwards community.

When we encounter a missing mass-update capability, find a workaround, and move on, we’ve solved our immediate problem. But what if dozens of other organizations are doing exactly the same thing?

Paul made a compelling case for bringing those needs to the Special Interest Groups and submitting enhancement requests. After all, how can product development address a problem nobody knows exists?

Midwesternism of the Day

This week’s Midwesternism takes us back to those everyday expressions that seem to slip naturally into conversation around the Midwest. It’s something we might say when we’re spending a little time tinkering with a project, perhaps with no particular urgency or even a clear destination. We had some fun debating the subtle differences in meaning, and even wandered into a little family history.

Until next time, let’s keep learning, sharing, and most importantly, laughing together.

Toodles!

Missed an episode? Check out the full episode list! Also, be sure to subscribe on your favorite podcast provider, or select a provider below!

Learn More

Quest Oracle Community is where you learn. Ask questions, find answers, swap stories and connect to other JD Edwards customers and product experts in the JD Edwards Community, where you can also check out what’s happening in the Business Analyst SIG.