Question Unable to launch “User and Group Accounts” dialogue box in *.mde file when running an (1 Viewer)

jeffreymiller

New member
Local time
Today, 10:35
Joined
Apr 20, 2013
Messages
6
I have an Access 2003 database application with user-level security which now needs to run on Access 2016. I’ve made all necessary updates so it runs almost without a hitch in Access 2016. Everything works fine except for being able to open the “User and Group Accounts” dialogue box when I save it as an *.mde file. I have a command button with the following “On Click: [Event Procedure]:

Private Sub CmndSecurity_Click()
On Error GoTo Err_CmndSecurity_Click
' check if current user is in Admins
If CurrentUserInGroup("Admins") = True Then
'Displays the Security User and Group Accounts dialog box
RunCommand (acCmdUserAndGroupAccounts)
Else
' If current user is not in the Admins group display the following message
MsgBox ("You must have Admins permission to access Security Accounts")
End If
Exit_CmndSecurity_Click:
Exit Sub
Err_CmndSecurity_Click:
MsgBox Err.Description
Resume Exit_CmndSecurity_Click
End Sub

When I click on the command button in the *.mdb file the “User and Group Accounts” dialogue box opens successfully. However, when I save my application as an *.mde file and click on the command button, the following error occurs: “Microsoft Access has stopped working
A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available.”
Any idea why it works in the *.mdb version and not the *.mde version?
Your insight would be greatly appreciated.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 09:35
Joined
Feb 28, 2001
Messages
26,999
To be honest, I'm rather surprised that Ac2016 will let you do that for the .MDB, even if it WAS based on a DB developed in Ac2003. The intrinsic Access user/group security is a declining -no, make that DECLINED - feature, removed because the MDAC module was buggier than an entomology museum and was the cause an incredible amount of patching requirements.

On the other hand, I've not worked with .MDE files much. By any chance did it tell you anything about converting the DB format when it was doing the .MDE conversion? Because if it did, the problem is that the feature you seek isn't IN Ac2016 databases.

If it didn't convert, then I have to back off because of limited experience with compiled databases and their implications.
 

jeffreymiller

New member
Local time
Today, 10:35
Joined
Apr 20, 2013
Messages
6
It converted without a hitch (i.e. no error or warning messages).

According to Microsoft Support "You can continue to manage user-level security in database files that use an earlier Access file format (such as an .mdb or .ade file" I would assume it applies to *.mde file as well since it's an earlier format (i.e. I know it dates back at least to Access 2003). This is all spelled out in their article entitled "What happened to user-level security?". Unfortunately this site won't allow me to post the link. There's more than one article with the same title at support.office.com ... I'm referring to the one that "Applies To: Access 2016 Access 2013”.

So I refer back to my original question; why does it work in the *.mdb version and not the *.mde version? Do I need to modify my vba code?
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 09:35
Joined
Feb 28, 2001
Messages
26,999
Unfortunately this site won't allow me to post the link.

Understood - there is a "minimum of 10 posts" limit on including links because a while back we had some people who tried to use this site for advertising in a way not authorized by Jon, our site master.

I don't have a clue as to why it is not working - and neither will anyone else who hasn't run into this problem. But I can tell you where to look to GET a clue.

Be sure that you have a time showing on your desktop. Perhaps use the "clock" gadget. Launch your .MDE file, fully expecting it to fail.

Now open up the Control Panel, get to the Administrative Tools, and open up the Event Viewer. Either the SYSTEM or the APPLICATION log should have something for the time of day at which you launched the .MDE file, so read that. Tell us what Windows said was wrong with whatever happened at that time.
 

jeffreymiller

New member
Local time
Today, 10:35
Joined
Apr 20, 2013
Messages
6
Hello Doc,
I'm hoping someone on this site has run into this problem and can help with a fix. In the mean time here's the Event created when my application bombs. Your insight would be appreciated:

General Tab:


Faulting application name: MSACCESS.EXE, version: 16.0.7571.2109, time stamp: 0x58643f42
Faulting module name: COMCTL32.dll, version: 6.10.14393.447, time stamp: 0x5819bcf0
Exception code: 0xc0000005
Fault offset: 0x000000000003c3f1
Faulting process id: 0x1f58
Faulting application start time: 0x01d2799961102812
Faulting application path: C:\Program Files\Microsoft Office\root\Office16\MSACCESS.EXE
Faulting module path: C:\WINDOWS\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.14393.447_none_42191651c6827bb3\COMCTL32.dll
Report Id: a6f1f45b-e58c-11e6-892a-28f10e3af0e8
Faulting package full name:
Faulting package-relative application ID:

Details Tab:

System
- Provider
[ Name] Application Error

- EventID 1000
[ Qualifiers] 0

Level 2

Task 100

Keywords 0x80000000000000

- TimeCreated
[ SystemTime] 2017-01-28T19:04:55.043554700Z

EventRecordID 23669

Channel Application

Computer INSPIRON-15

Security

- EventData
MSACCESS.EXE
16.0.7571.2109
58643f42
COMCTL32.dll
6.10.14393.447
5819bcf0
c0000005
000000000003c3f1
1f58
01d2799961102812
C:\Program Files\Microsoft Office\root\Office16\MSACCESS.EXE
C:\WINDOWS\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.14393.447_none_42191651c6827bb3\COMCTL32.dll
a6f1f45b-e58c-11e6-892a-28f10e3af0e8
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 09:35
Joined
Feb 28, 2001
Messages
26,999
Exception code 0xc0000005 is "Cannot start application" - but the error DID call out the COMCTL32 file. You might read these links, which contain other links as follow-up. A couple of the linked articles suggest a specific type of corruption after a "ragged" update, or perhaps a hack/virus problem somewhere.

https://answers.microsoft.com/en-us...stalling/53777909-95b4-4df8-a1ea-6efc226977f3

http://www.eassos.com/how-to/fix-error-code-0xc0000005.php

http://windows-exe-errors.com/fix-windows-7-installation-error-code-0xc0000005/

https://appuals.com/best-fix-the-application-was-unable-to-start-correctly-0xc0000005/

https://www.sevenforums.com/windows...36-error-0xc0000005-after-windows-update.html

The exception is calling out both MSACCESS.EXE and COMCTL32.DLL, the latter file being something that might occur in one of the references. I don't have COMCTL32.DLL but I DO have COMCTL32.OCX in my database references. Microsoft is crazy but they aren't stupid, so COMCTL32.DLL and COMCTL32.OCX contain the same functions but are loaded a little differently. Either way, COMCTL32.??? is the file for the "Windows Common Controls" library.

So in the .MDB version open a code window, then follow Tools>>References and in the list that shows up, be sure that COMCTL32.DLL is referenced. The names for the modules don't always exactly match the names of the files involved, but you can try to look at the details under each reference that you highlight. You might have to do a file search for COMCTL32.* to see if you can locate both/either file on your system.

Another alternative is to read the articles and look your windows update history, which you can do by opening Windows Update and look at the list of options on the left. One of the options, if you click it, will show you the list of updates in chronological order, most recent update at the top. The articles call out various and sundry updates, one of which could be the culprit. Read the articles very carefully if you are about to do something drastic like undo an update, because they have to include instructions on how to tell your system to disallow that update.


I invite the other forum members who have more experience with compiled Access to look at this and see whether they have run into this kind of problem. At this point all I can do is point to the fact that there are issues with starting the file.
 

jeffreymiller

New member
Local time
Today, 10:35
Joined
Apr 20, 2013
Messages
6
Hi Doc,
Thanks for your valuable insight. When I open up the code window and access the "References" window, COMCTL32.*** isn't shown as an available reference. So I hit the "Browse" button and located COMCTL32.dll in my C:\Windows\System32 folder. Then I selected it and hit "Open" and received the following VBA message: "Can't add a reference to the specified file". So I'm unable to add it to my list of "Available References". What specified file is it referring to? Is it trying to add it to my database file? Any suggestions on what I might try next? FYI I'm running Access 2016 64 bit on my Windows 10 computer and this database application was originally created with Access 2003 32 bit. Looking forward to your reply. Sincerely, Jeff
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 09:35
Joined
Feb 28, 2001
Messages
26,999
Jeffrey - your "references" list is kept in the Windows Registry under the HKEY_LOCAL_SOFTWARE or HKEY_LOCAL_USER hive (don't remember which.) The ability to add to the registry is normally a privilege or a permissions-based right (the ability to write to the selected hive, because registry entries can have permissions.)

The inability to add a reference would make me question whether (a) you are not an admin user of the system or (b) your database is not trusted (whereas COMCTL32.DLL is trusted).

The fact that your COMCTL32.DLL isn't referenced actually makes that error much clearer, I think. You can see that the file named in the event log entry is not present, so that might explain the "why" - but doesn't tell why the .MDB can run and the .MDE cannot. Then again, Windows is like that song from Jesus Christ, Superstar - Microsoft is pretty keen on how and when, but not why.
 

jeffreymiller

New member
Local time
Today, 10:35
Joined
Apr 20, 2013
Messages
6
Hi Doc,
Thanks for your quick reply. I went into my Windows account settings and verified I'm the "Administrator". FYI it's my computer and I'm the sole user. Then I opened Access and verified the folder in which my database is located is in fact a "trusted location". Do I additionally need to make my database file itself "trusted" (i.e. *.mdb)? If so how do I go about that? Andy other ideas or suggestions? Thanks again for your assistance!!!
Sincerely, Jeff
 

CJ_London

Super Moderator
Staff member
Local time
Today, 14:35
Joined
Feb 19, 2013
Messages
16,553
FYI I'm running Access 2016 64 bit on my Windows 10 computer
So far as I am aware, 64bit access will not run 32bit compiled code (or visa versa). And mdes are 32bit.

if running a mdb, the code is compiled at runtime which is why it appears to work OK because it is converting it to 64bit (subject to mods for ptrsafe and longptrs for any API's)

In particular take note of this paragraph

Native 64-bit processes in Office 2010 cannot load 32-bit binaries. This is expected to be a common issue when you have existing Microsoft ActiveX controls and existing add-ins,

in this link https://msdn.microsoft.com/en-us/li...2bit64bit_Comparing32BitSystemsto64BitSystems

So I suspect your only solutions if you want to keep user groups is to replace access 64bit with 32bit or to provide users with mdb's

If you upgrade your app to .accdb/e then you will lose the user group functionality anyway.

I did find these links

http://stackoverflow.com/questions/12270453/ms-access-db-engine-32-bit-with-office-64-bit

https://knowledge.autodesk.com/supp...rivers-alongside-32-bit-Microsoft-Office.html

which are about installing 64bit runtime alongside 32bit access (which I also understood was not possible, but hey, maybe not). Perhaps you can 'reverse' this to install 32bit runtime alongside 64bit
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 09:35
Joined
Feb 28, 2001
Messages
26,999
Ouch! Missed that point, CJ, because I have not played with .MDE that much. I'll have to file that one away for future reference.

Jeffrey, the problem is that COMCTL32 is a 32-bit .DLL but you are running a 64-bit version of Access. That is why you can't make the reference.

Follow CJ's links. They may be helpful for your case. By the way, if you are not using SharePoint or any other 64-bit functionality, you don't need the 64-bit versions of Office. You can do just fine with 32-bit. And the good news is that if you have an installation disk, it is a simple choice when you start the installation to choose 32-bit. You WILL have to remove the 64-bit version first, though, unless CJ's links help you set up a simultaneous install of both versions at once.
 

jeffreymiller

New member
Local time
Today, 10:35
Joined
Apr 20, 2013
Messages
6
CJ,
You hit the nail on the head. I uninstalled Office 64 bit and reinstalled Office 32 bit and voila ... no more issues with the mde. You're a genius!!! Doc your guidance was helpful as well and much appreciated. Have a great day! Jeff
 

Users who are viewing this thread

Top Bottom