Blog

A common misconception holds that — when deployed in a split database configuration —Microsoft Access must retrieve entire tables across the network share before it can process any SQL statement or join. Sometimes, it is even directly stated that WHERE clauses and JOINs are applied only after all rows have been pulled to the client. It’s occasionally expressed as Access does no processing in the Back End accdb.

This is factually incorrect and contradicts decades of Microsoft documentation on the Jet/ACE query engine.

The shift I've experienced in just a few months has been dramatic. The gap between "AI as an interesting toy" and "AI as a genuine force multiplier" has closed faster than I ever believed possible.

Which brings me to the central point of this post: If you're not using an AI assistant in your work today, your replacement almost certainly will be, and sooner than you think.

A long time ago, my then-fellow Access MVP Jeff Boyce characterized Access developers this way:

When someone suggests a crazy idea for a software project, Access developers are the ones who say, "I'll try that. How hard could it be?"

It's an attitude that serves us well, most of the time. And I think the prospect of integrating AI into our development work falls neatly into line here. But, before you dive into the deep end of the pool, I want to offer another, countervailing, thought. "Just because you can do it, doesn't mean you should."

Let's discuss the issues.

The explosive growth of AI assistance opens a lot of opportunity for Access developers to explore alternatives. Is it worthwhile for Access developers to invest time and resources in pursuing other alternatives?

I posed the question to Claude Chat....

One of the lessons I've had to learn the hard way: Not only can AI make mistakes, it can't anticipate and prevent my mistakes. Shocking, isn't it?

Is it Null? Is it a ZLS? Is it a Blank? Access developers soon learn the difference. Sometimes, though, I think PowerApps just doesn't get it.

Rather than whinge about it, it turns out the best way to deal with that ambiguity is just a simple guard function in your PowerApps formulas. Let me show you how that works.