[RESOLVED] Legacy App Error: "Cannot open the microsoft jet engine workgroup information file"

Hi,

I've just gotten reports from users at two separate offices that they can no longer open their Jet database created files in a legacy VB6 application today (out of the blue). The error is:

"Couldn't open connection. Cannot Open the Microsoft Jet Engine Workgroup Information File"

I haven't been able to reproduce the problem on any of my test systems yet, but I was wondering if anyone bumped into this after the most recent MS update as well, and maybe found a solution? I'll post back as well if I find the solution myself.

Thanks in advance for any help.

Questions:

Which versions of Windows?

Are the MDB and MDW files in a protected filesystem location?

Are you even using an MDW you created for your MDB or are you defaulting to the system MDW (almost always a poor idea)? A lot of coders don't even know they are doing this, see Unveiling System.MDW

Hi Dilettante, thanks for the reply, and sorry for the lack of info, I'm still trying to collect information, and figure out a pattern.

I know one user is using Windows 7, the other site hasn't gotten back to me yet. They also have Office 2007 installed (as do I on my test system here, but I don't have Access and they do). They report that a MS update went through today, and then the problem started, but I also installed MS updates here today and I don't have the problem. So that's just a hunch (maybe if there was an Office update that did something with Access that would affect Jet databases?)

Just to be clear about some things in the legacy app:

• The code hasn't been changed in a year (at least), the affected sites haven't updated our software in a long time.
• I got one of the users to re-install my software, but that didn't help.
• My software doesn't use MDW, and there is no db level-user accounts/passwords.
• Files are not stored in a protected location AFAIK - users can create "projects" which are just MDB files, and they are typically stored in their document folders (again AFAIK, but there have been no problems accessing these files even as of yesterday).
• It looks like the databases are being created using Jet 2.8 - I've recently seen some of your posts recommending using older versions of Jet, so maybe the problem lies here?

I haven't been actively involved with the old code for a few years, and the new version of the software doesn't use Jet or connection strings, so my expertise is lacking here. It's also taking some time to dig through the code and get re-familiar with it.

The code that attempts to open the database is:

Code:

---

      ChDir Left(Filepath, InStrRev(Filepath, "\") - 1)
      conProject.ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & Filepath 
      If IsHomeOffice Or Exclusive Then
        conProject.Mode = adModeShareExclusive
      Else
        conProject.Mode = adModeShareDenyNone
      End If
      conProject.Open

---

Do you notice anything wrong with this? Maybe something missing from the connection string?

Hi,

Were getting the same problem, and it looks like its either Windows update or Kaspersky AV that caused the problem. Was able to fix it by getting a copy of System.mdw (should be installed by access) then copying it to the users ...\System32 directory. Once you have done that amend the HKLM\Software\Microsoft\Jet\4.0\Engines\SystemDB key in the registry so it contains the full path (including filename) of the System.mdw file you placed in system32.

Regards

This is interesting - I've just had a call from a customer who has a VB6 application out in the wild, and has had the same error reported by two of his customers.

They're running Windows 7 and Windows 8. No application updates have taken place, and he's not aware of any Microsoft updates this week which may affect the system. However, it's spooky.

Sounds like there has been an update which is affecting you and my customer's customers.

He's tried reinstating a known previously good copy of system.mdw, with no effect.

It could well be a permissions problem with the file. I'll check where on the PCs the system.mdw are being held.

Quote:

---

Originally Posted by regbarnes

Hi,

Were getting the same problem, and it looks like its either Windows update or Kaspersky AV that caused the problem. Was able to fix it by getting a copy of System.mdw (should be installed by access) then copying it to the users ...\System32 directory. Once you have done that amend the HKLM\Software\Microsoft\Jet\4.0\Engines\SystemDB key in the registry so it contains the full path (including filename) of the System.mdw file you placed in system32.

Regards

---

Posts crossed - thanks Reg I'll try that.

Thanks for your replies! I will be see if I can get the client to replace the file as described and see if that works.

We had a simular issue this morning. A rogue system.mdb file appeared on the desktop of every user running access type database. The file was 0 bytes long. Once this file was deleted our application worked without issue. We are running windows 7. After rebooting the system.mdb file did not return to the desktop. My suggestion would be to look for a system.mdb file that has 0 bytes and delete it (after a backup of it of course).

Deleting the rogue system.mdb file does not work.

The solution for putting a system.mdw in sys32 and then putting that path into the registry worked on an XP machine.

However, I cannot find that registry item on Win 7.

Attention everyone, the problem is being caused by Kaspersky AV Software

See this thread for more information: http://forum.kaspersky.com/index.php...gopid=2218158&

The "System Watcher" process is causing any application trying to access a Jet DB file to create a 0kb System.mdb file in the application directory. This file prevents the application from functioning properly.

Current workaround is to delete the file and disable system watcher so that it doesn't get recreated. Kaspersky seems to be working on a fix.

Can confirm that Kaspersky is the common denominator for me too. Thanks again everyone for your help!

Of course using your own application "system database" (normally a .MDW file) this shouldn't be an issue because you don't touch System32 files that way.