BUG ALERT: No Current Record

"OK, campers, rise and shine!  And don't forget your booties 'cause it's cooooold out there today!"

Patch Tuesday is starting to feel like Groundhog's Day for Microsoft Access developers.  

No Current Record

Reports of the latest Microsoft Access update-related bug started popping up yesterday, May 10, 2022:

• "No current record" error now affecting all versions of my database
• Access Broken today 10th May 2022

Former Access MVP Gina Whipp reported some symptoms of the bug here: ^{(posted at 2022-05-10 16:39 EDT)}

Hmm, having the same fun today. Your error look anything like this?

• Property not found
• No current record.
• The search key was not found in any record.
• The object doesn’t contain the Automation object ‘txtPurchaseOrde.’ (And while that is control on the Form it is not used in the code anywhere. Oh, and yes that is the way it is spelled in the message but not on the Form.)

And Like That...*POOF*...He's Gone

As fast as the error appeared...it went away just as quickly.

Some might say, alarmingly quickly: ^{(posted at 2022-05-11 16:25 EDT)}

I've just tested and the problem appears to have gone.

But there has been no update, rollback or change of version.

What on earth is going on? How can Microsoft affect the behaviour of Access without an update of Office or Windows? Is the problem with some sort of live link - perhaps the licensing/activation?

An explanation is needed.

---

UPDATE:

I've just spoken to the client, who is working late because of all the time lost. They haven't even closed Access, they just left it running when they stopped for a meal. The problem has gone away.

They didn't even close Access. What is going on here?

In other words, the entire life cycle of the bug appeared to be about 24 hours.

Pulling Back the Curtain

So how did this bug appear and then–as if by magic–just as suddenly disappear?

I posed that question to the Access engineering team on the Microsoft MVP NDA (non-disclosure agreement) mailing list.  The folks at Microsoft provided the following explanation (approved for public release beyond the NDA mailing list):

When we ship changes we always try to wrap them in something called a ChangeGate or FeatureGate. This is how we can contain the impact on any change on customers as soon as possible if it breaks something unexpected. Basically when an office app loads it requests statuses of these gates from the network, to determine if the code its wrapping should execute or not. That way if the new code causes a regression, we can change a setting on a service on our side and when a user restarts the app the issue should be resolved.  This is how we can contain the impact on any change on customers as soon as possible.

A Little Too Much Magic

I appreciate the responsiveness that this approach allows for.

As we saw today, targeted bug fixes can be rolled out almost instantly on a global scale.  I think we should take a minute to reflect on how cool that is.  It's easy to get caught up in the bugs themselves, but Microsoft really is trying to find ways to minimize their impact.

The problem is that there is no way for the end user to verify or explicitly force a fix through this system.

And that is a real problem for intermittent bugs that are hard to reproduce.

It's not hard to imagine a scenario where a newly introduced bug causes data corruption in a small number of edge cases.  If I'm an IT admin, I'm not letting anybody run Access until I know that bug has been addressed.  The FeatureGate system–as currently implemented–does not support that.

A Modest Proposal

I'm not saying we need to throw the baby out with the bathwater.

The ability for Microsoft to rollback updates at the level of individual features is very powerful.  And it's a huge step in the right direction.  But we NEED a way to verify whether or not an individual installation of Access has some bug fix turned on or off.

More broadly speaking, it would be nice if we had some way through the Access object model in VBA to get more information about the running copy of Access:

• What is the version number? (SysCmd(acSysCmdAccessVer) returns 16.0 for every version of Access starting with 2016)
• What is the build number?
• What is the bitness? (so we don't have to resort to hacks, even simple ones)
• What is the licensing level? (since that is apparently more important than version/build number these days)

I'm OK with making this some undocumented SysCmd, but we need to have something.

External references