Forum Discussion
Problem with MSJET40 Started in May 2020 - Rapidly Inflating database until 2Gb then stops working
Beginning in May, on Windows 10, new versions of the Jet Database Engine components were released as part of multiple KB Windows Updates (many as of now):
- msjet40.dll version: v4.00.9801.25
- msrd3x40.dll version: v4.00.9801.25
Immediately our Astronomy Observatory Scheduling System, which uses the Jet database via .NET System.Data.OleDB, started seeing wildly rapid inflation of the database even with just reading data, no insertions or updates. The application is complex, depending on Stored Procedures (QueryDefs) and referential integrity links. The application first went to production in 2004, and has been operating with MSJet 100% trouble free, really zero database problems at all, for 15+ years! Now we have several commercial sites and many more university and private sites that are struggling.
The JETCOMP utility requires all connections to the database be closed to compress. These facilities serve multiple remote customers with images being acquired by the telescopes and users entering and browsing observing requests 24/7. It is not good to shut everything down to compress and we never had to shut down before (it all just ran). At some sites the 2Gb limit is reached in a day or two, where the normal size for the database is a couple of hundred megabytes or less. Several of our customers, who were already disgusted with Windows 10 updates, have reverted to Windows 7 and they are now happy (we're not because we must continue to support W7).
We're trying to get a repro kit together but it's difficult to create a "simple" demo as the problem happens with multiple open database connections. If you do some queries and then drop the connection to the database, it remains at its current size. If you open a connection, then another from another program (these would each have their own loaded COM/JET components), then do queries, close the connection, the database inflates. This is what it looks like right now but the behavior is inconsistent while we're trying to zero in on it,
We have code to handle collisions between multiple programs reading and writing the database and we tested this logic thoroughly back in 2004. As I said all of this worked flawlessly for 15+ years. We're shooting in the dark because we don't really understand what was broken in May.
Meanwhile we have some customers who have replaced the broken MSJet components with the last ones that worked:
- msjet40.dll version: v4.00.9801.20
- msrd3x40.dll version: v4.00.9801.19
Needless to say we are not happy with this "solution". We have reported this via the Feedback Hub three times. I just found out about this Tech Community service (and yes I have been a dev "forever"). I'll do anything within reason to help, but at least I'd like to know the Jet devs know about it. I don't know how else to reach them. Maybe just knowing what's happening, and looking at what they changed between .20/.19 and .25/.25 a light bulb might go on? Anyway Help!
I received a response from the MS Access team.
"This was caused by a security update. The Windows team is aware of the issue, and plans to release a fix for this ....Note that the Access team doesn’t own/update msjet40.dll, it is a Windows system component."
I wish we had better a better timeline, but they are working on it.
- George_HepworthSilver Contributor
DakotaDreamer I'll make sure someone on the MS Access dev team knows about your problem.
- George_HepworthSilver Contributor
I received a response from the MS Access team.
"This was caused by a security update. The Windows team is aware of the issue, and plans to release a fix for this ....Note that the Access team doesn’t own/update msjet40.dll, it is a Windows system component."
I wish we had better a better timeline, but they are working on it.
- DakotaDreamerCopper Contributor
George_Hepworth I marked your responses "best" but forgot to thank you... THANK YOU for passing this along and for reporting back that they are on it. It was a great relief to me and to our astronomy community.