KB5002121 breaks MS Access runtime applications

hi,

I had the same behavior, I solved it by uninstalling the Kb5002121 for Access 2013 and KB5002112 for Access 2016

bye

Giorgio Rancati

We're currently having the same stupid behavior on some of our work machines. At least two users have reported broken exports to Excel & RTF text files from MS Access. I'm currently trying to uninstall KB5002112 for Access/Office 2016.

Wouldn't be the first time some stupid update has broken MS Access, requiring me to manually remove the update from machines company-wide and run the "don't reinstall this update" tool on them... Ugh...

Now, if they'd just fix the other damn "System Resource Exceeded" bug on multi-core machines [that's been around for a decade, it seems like]... That bug is ALSO the bane of my existence. Users don't know the first thing about setting CPU affinity to 0, or whatever. And they shouldn't have to in the first place. This bug should have been quashed years ago... But, it seems like M$ doesn't give a rip about it, and are happy to let users suffer in silence.

Yep, after uninstall of KB5002112 and running the show/hide updates troubleshooter to tell it not to reinstall the update, we're able to export text & excel docs from Access again ,apparently one of the many fun things "broken" by the update.

Anyway, thanks for the heads up. Not looking forward to manually uninstalling the update on the 25+ machines around the office, and running the show/hide tool, which takes a while. And of course I'll probably have to run ALL updates on all machines just to get them up to the point they see the update to begin with, in order to uninstall/reinstall it. Probably gonna' be another dumb "weekend project" to avoid colliding with users remoting into their system(s)...

Joy of all joys! :\

KB5002048 should not introduce this error.

Hi Denis,

I can confirm for all versions of office 365 published on 12. July (and we came into contact) the bug is in. And only reliable woraround is the simple extar start up form. And yes, too early click brings the error and requires a new click.

We sent out such updates to our bigger customers. So that our app is updated before the office.
So they can use our internal update system. Bug braeks the internal update and each client has to be updated manually (up to 1000 at one customer).

For small customers we only sent a warning and do special update on error message from customer.

At least one customer temporay changed to "actual channel" and will go back to monthly/half year later.

Really frustrating big workload and no smart solution.

Wolfram

We noted that issues persisted with the previously stated updates (KB5002121, KB5002112) and another one I haven't seen in here KB5002048.

I have the same issue as others here. There are about 50 client users and our IT group Update policy has only affected a few users so far. I am sure more will be complaining soon. I am in a very large global corporation....I doubt the IT group will agree to roll back the Update.

I tried the Autoexec Macro but got the same error in my situation.

I tried the simple startup form with only a button to open the desired Login form. This works as long as I wait ~4-8 seconds before clicking on the button. ughhh. I tried a timer to force 7 second delay, but Runtime with ACCDE can't seem to handle the Timer.

If I use an uncompiled ACCDB file with Runtime it does ok. But I am concerns some users with Full Dvp Access can get to the VBA code and/or backend data via linked tables behind the Frontend. I have disabled the Special Access Keys, but not sure that is very secure. Any comments on that?

Thank you!! Denis