ACCDE fails to load VBA on random workstations

[agiercke]

I have created a database to track leave requests for staff. After upgrading from XP to Win7 and upgrading to Access 2010, some workstations will not run the ACCDE front end, but the ACCDB runs fine.

I am storing the front end ACCDE in C:\Users\%username%\appdata\Roaming which is trusted - and I do not receive a warning for this. When the ACCDE loads I receive the message that "The database cannot be opened because the VBA project contained in it cannot be read.". I have tried running the application with different users to eliminate privilege issues. All the workstations are built from the same image and I cannot find any missing references or different patches. The workstations in question are running RUNTIME version.

I have checked for missing references in the dev version. I have compiled the database right before creating the ACCDE, finally I have run the app with the -DECOMPILE option.

I appreciate any advice in trying to isolate this issue. I am sure there is something different on the machines, but I cannot determine what that is.



Allan

[orange]

I don't have an answer. Do the users have permission to read/write in that location? Where is the backend located? I have been reading some user group info recently where permissions(or lack of) has locked the backend from users making it exclusive.

[amrut]

Apart from above suggestion, check the version number of VBE7.dll located here C:\Program Files (x86)\Common Files\microsoft shared\VBA\VBA7 on development machine and target machine. I faced this problem with WinXP +Access 2010 runtime on one machine as the VBE7.dll version was lower than the development machine. A workaround I used was to decompile the database and compile using the VBE7.dll file from the target machine copied to development machine. I am not sure whether this method, though solved my problem, was correct or not.
Here is a article from ms knowledge base http://support.microsoft.com/kb/2533794

[agiercke]

Thanks for the input - it appears to be related to VBE7.DLL - the development and working systems are running v7.00.16.27 and the problem systems have v7.00.15.00 - next step will be to work with the packaging team to determine why some systems are not at the latest level.

Allan