2

I have a Microsoft Access Application (.mdb) that is old and proprietary and needs to be run on Windows 10 in Microsoft Office 2016.

The frontend (.mde) for it needs some old .ocx controls, and I've narrowed it down to it needing a library (link1, link2), but I cannot use Tools->References to add anything to it;

The administrator password for the database is not something that I have. So I was wondering if there was a way to add ocx controls to MS Access globally so they are added in all products.

When trying to open it, I get the error:

The expression On Open you entered as the event property setting produced the following error: The Open Form action was canceled.

*The expression may not result in the name of a macro, the name of a user-defined function, or [Event Procedure]. *There may have been an error evaluating the function, event, or macro.

This error occurs when an event has failed to run because the location of the logic for the event cannot be evaluated. For example, if the OnOpen property of a form is set to =[Field], this error occurs because a macro or event name is expected to run when the event occurs.

Community
  • 1
  • 1
leeand00
  • 25,510
  • 39
  • 140
  • 297
  • 1
    The answer to the question is (I'm fairly certain) no. Have you re-registered the .ocx ? What is the error message you get when running the application? – Andre Aug 11 '16 at 16:31
  • You might be able to do it with an installer (like Inno Setup) if you can use that to install and setup your front-end. By installing the old controls into the App folder and having the installer register them before the app gets opened... it _Might_ work – dbmitch Aug 11 '16 at 16:39
  • @Andre I tried using running the batch file specified in Method 4 here: https://support.microsoft.com/en-us/kb/2748410 – leeand00 Aug 11 '16 at 17:27
  • But the registry key doesn't exist. I also copied over `MSCOMCTL.OCX` (from an old server 2003 machine) into both `C:\windows\syswow64\` and the directory where the file is. Same error message. – leeand00 Aug 11 '16 at 17:28
  • You copied them, but did you `REGSVR32` them? – random_answer_guy Aug 11 '16 at 19:58
  • Just so we understand the situation: The original .mdb is password protected (or is it Access security with an .mdw file?), and the .mde generated from the .mdb doesn't work? Or how are .mdb and .mde related? – Andre Aug 11 '16 at 21:18
  • If you create a new database, and in form design add an ActiveX control. Do you get `Microsoft TreeView Control, version 6.0` in the list? If no, then MSCOMCTL.OCX isn't correctly installed/registered. Try https://www.microsoft.com/en-us/download/details.aspx?id=10019 – Andre Aug 11 '16 at 21:22
  • @Andre It's an mde file that you open with an mdw file, and the mde doesn't let you get at the VBA code or let you get at the references. – leeand00 Aug 11 '16 at 21:43
  • @random_answer_guy I did try the regsvr32 /u and after regsvr32 and they both report success. – leeand00 Aug 11 '16 at 21:45
  • A mde is a compiled version of a mdb, so no VBA and no access to references. Does the original mdb still exist? That's your key to the solution. – Andre Aug 11 '16 at 23:00
  • @Andre I'll bet the company that made it still has the mdb that made the mde. – leeand00 Aug 12 '16 at 00:34
  • @Andre ya know; it works in Windows 7, on Access 2007 and on Win 7 in Office 2003 as I have both of them installed on my machine; I'll be that since that registry key isn't on the Windows 10 machine, I bet that's why it doesn't work; I'll have to see if the registry key is on the Windows 7 box. – leeand00 Aug 12 '16 at 03:12
  • Make sure you have the exact same version of MSCOMCTL.OCX as you have on a computer where it works. It only belongs in C:\Windows\SysWOW64 , nowhere else. And must be registered with that path. – Andre Aug 12 '16 at 07:39
  • I do have the tree view control. But the MSCOMCTL.OCX isn't in my `C:\windows\syswow64\` – leeand00 Aug 12 '16 at 12:23
  • @Andre I mean on Windows 10...But it is however in `C:\Program Files (x86)\Microsoft Office\root\VFS\SystemX86`. – leeand00 Aug 12 '16 at 12:48
  • Huh. Is this Office 2016 **64bit**? Then I doubt it's possible to get it to work. But in any case, unregister that, and register it from C:\Windows\SysWOW64 (copy the file there). – Andre Aug 12 '16 at 13:02
  • @andre I also noticed that the version in `C:\Windows\SysWow64` on windows 7 is `6.1.98.39` (according to right-click properties, details tab) and the same thing on the one that is in `C:\Program Files (x86)\Microsoft Office\root\VFS\SystemX86` on Windows 10 is `6.1.98.46` – leeand00 Aug 12 '16 at 13:25
  • @Andre Also, the registry key is in `HKCR:\typelib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}\2.0` on Win7, but it's missing from Windows 10 in the same location in the registry (actually in Windows 10, `HKCR:\typelib` exists, but the GUID for the class does not. – leeand00 Aug 12 '16 at 13:26
  • @Andre Okay I'll try it. – leeand00 Aug 12 '16 at 13:26
  • Heh, I think this is what used to be called "DLL hell". My version in C:\Windows\SysWOW64 is also 6.1.98.46, so let's assume that this is the current one. But as I wrote earlier: you should use the exact same version as on a computer where it works (or worked). Using a different .ocx version than the .mde was created with can lead to compile errors (which is your error message in the question). Normally this is resolved by removing the old reference and adding the reference to the new ocx, but since you can't do that, try to use the original ocx version. – Andre Aug 12 '16 at 13:46

1 Answers1

0

An Access MDE is a compiled version of an MDB. The VBA projects in MDE files are compiled to a specific bitness and cannot be changed, so an MDE/ACCDE created under 32-bit Office will not work in 64-bit Office, just as an MDE/ACCDE created in 64-bit Office will not work in 32-bit Office.

Likewise, references to controls, and to some Type Libraries, might require the MDE to be re-created after a change of Windows version, regardless of whether you've changed from 32-bit Office to 64-bit Office.

For example, Office 2016 uses a different version of VBA to earlier versions of Office, so the VBA project would not be able to run in Office 2016 if it was compiled under an earlier version of VBA. Although this article relates to Office 2010, it is still informative:

This issue occurs because Access 2010 SP1 uses a newer version of the VBE7.dll file (version 7.00.1619)

If you are using 64-bit Office, it's possible that your MDE was pointing at Common Control Library (which isn't available for 64-bit Office), but your MDE might also be linking to Type Libraries that are only suitable for 32-bit usage (for example, Type Libraries built using VB6)

In order to diagnose this problem thoroughly, you really need to work with the original MDB that was used to create the MDE. If you need to re-create the MDE from the original MDB, but you need to salvage data from the problematic MDE, you may still be able to import data from it using the tools in Access.

If you don't have access to the original MDB, then you may need to find a PC with the correct version of Windows and Office, and any controls and Libraries, just to carry on using the file. You may be able to salvage some code by paying for a third-party service such as http://www.everythingaccess.com/mdeconversion.asp (no affiliation)

ThunderFrame
  • 9,352
  • 2
  • 29
  • 60