VBA Project cannot be read

[fat controller]

I have a database that is running on numerous PC's across various sites, and for the most part, it runs without any issue at all. It is what I am sure would be considered as 'fairly standard' in terms of its configuration with a front end .accde file that resides on a user's PC, with the back-end on a network server. User's PC's run the database using Access Runtime 2010 (again, installed locally on each user's PC)

Over the past week or so, two PC's at one location have been replaced with new ones running Windows 7, Office 2010 as standard (no Access component), and neither of those machines will run the database, both coming up with an error message which states that the VBA project cannot be read.

I have tried getting the users to delete their front end file and then replacing it with a known good copy, to no avail. Every other PC we have will run a copy of the same file without question - it is just these two new machines.

I have not actually sat down in front of these PC's (they are at a location away from mine) nor can I access them remotely - remote access is being done by our IT department (the words ashtray and motorbike spring to mind!), who are passing the buck back to me as the developer of the database.

I have suggested that they uninstall both Office 2010 and the Access Runtime program, then reinstall after a reboot to see if that changes anything, however they have refused point blank stating that it is a database issue.

I have no doubt that I will end up having to go and put myself in front of these machines and resolve the problems myself (I have asked IT to give me admin rights on those PC's to allow me to do so), but I could do with some suggestions as to what I should be looking at?

As always, all help gratefully received.

 

[gemma-the-husky]

Over the past week or so, two PC's at one location have been replaced with new ones running Windows 7, Office 2010 as standard (no Access component), and neither of those machines will run the database, both coming up with an error message which states that the VBA project cannot be read

if they have office standard, (ie not professional) and no MS access, then they won't be able to open an access file.

Make sure the runtime is correctly installed. The project in the front end may be corrupt, in which case they need a new copy. If the data is corrupt, then it's a bigger issue, assuming the dbs is split

 

[pbaldy]

Is this applicable?

https://support.microsoft.com/en-us/kb/2533794

I love that they make you responsible but don't give you access.

 

[MarkK]

have been replaced with new ones running Windows 7, Office 2010 as standard (no Access component)

If neither Access nor a runtime version of Access is installed, then there is no way an Access database will run.

 

[MarkK]

Holy, you guys are all over it

 

[fat controller]

if they have office standard, (ie not professional) and no MS access, then they won't be able to open an access file.

Make sure the runtime is correctly installed. The project in the front end may be corrupt, in which case they need a new copy. If the data is corrupt, then it's a bigger issue, assuming the dbs is split

I have a feeling that this is where the problem lies - IT are telling me that they have installed the Runtime environment on the PC's concerned, but I am less than sure that I trust them.

A new front end file has been tried, still the same - yet, the same front end file can be moved across the network to another PC and it opens just fine. Data is not corrupt in the least - there are at least 6 other PC's in the same building all using the database without issue, and I can also access and use it just fine from my location (back end is on a shared server)

If neither Access nor a runtime version of Access is installed, then there is no way an Access database will run.

As above - Runtime is allegedly installed

Is this applicable?

https://support.microsoft.com/en-us/kb/2533794

I love that they make you responsible but don't give you access.

I had read that one, and the error message contained therein is exactly the message the users are getting; trouble is, I am compiling the database front ends on my company laptop which is running Office 2010 (with Access) and as far as I am aware it is not SP1. I am pretty sure that it is 64-bit, but then as far as I know the PC's concerned are also 64-bit

My home machine is running Office 2010 Professional Plus - I sometimes do design work on my home machines but the final compilation and distribution is done from my company laptop.

I always distribute the front end as .accde as well, as I am working under the impression that this keeps the VBA project safe from anyone trying to tamper?

Mid-way through typing this, I have managed to get one of our more experienced IT guys on the phone, and there is a possibility that they have installed the 2013 version of the Access Runtime on those two new machines - would this cause the problems I am seeing?

On the bright side, he has just agreed that I should be given admin rights on those PC's and is going to escalate things to give me techadmin status and Teamviewer remote access to solve issues like this. Are all IT departments completely in the dark about databases? Very few of the IT bods I have spoken to seem to have much of an understanding about databases - - its almost as though I am practicing witchcraft

 

[pbaldy]

Regarding "I am compiling the database front ends on my company laptop which is running Office 2010 (with Access) and as far as I am aware it is not SP1.", if the new PC's are SP1, that could be your problem (scenario 2).

 

[Minty]

Make sure they install the runtime AFTER they installed whatever office version they have installed. We have seen weird faults particularly when later versions of office are installed.

 

[The_Doc_Man]

With Access 2010, the default was a 32-bit version of Access. With 2013, the default changed to 64-bit versions. However, the 64-bit option WAS available for 2010. If someone else (your IT department folks) loaded the wrong flavor, that could mess you up because the DLL files are not necessarily fully compatible between 32-bit and 64-bit. For what it is worth, there is no requirement that you run 64-bit Access on a 64-bit machine. You can run 32-bit Access just fine as long as the DLLs files are the same "flavor."

I have no experience with the Access Run-Time component, but if there is a way to check it for broken references, I might look there first. There is also a way to have Access applications check their own references. You can try to step through Access.Application.References (a collection of reference objects) that includes such things as the file reference, the "broken" flag, and a couple of other properties. If you were unsure of having valid references, a little "For Each" loop that somehow outputs that collection to something you could call up using a surreptitious method (like double-clicking on what is normally a passive control) could help you validate what should be there.

 

[gemma-the-husky]

further to the docman's observations - when installing access, MS actually recommend the installation of 32 bit access, irrespective of the bitness of windows.

(does that mean 32 bit office in its entirety)

 

[fat controller]

Regarding "I am compiling the database front ends on my company laptop which is running Office 2010 (with Access) and as far as I am aware it is not SP1.", if the new PC's are SP1, that could be your problem (scenario 2).

Thank you - checked that too, and no they are not SP1; to quote the IT guy, they are just "plain old straight 2010, with only the basics like Word, Excel and Outlook"

Make sure they install the runtime AFTER they installed whatever office version they have installed. We have seen weird faults particularly when later versions of office are installed.

Thank you also - I will try this one. I am slightly miffed that they refused my suggestion to uninstall both the runtime environment and the Office package and reinstall them again, so that may yet happen when I get access to the PC's myself

With Access 2010, the default was a 32-bit version of Access. With 2013, the default changed to 64-bit versions. However, the 64-bit option WAS available for 2010. If someone else (your IT department folks) loaded the wrong flavor, that could mess you up because the DLL files are not necessarily fully compatible between 32-bit and 64-bit. For what it is worth, there is no requirement that you run 64-bit Access on a 64-bit machine. You can run 32-bit Access just fine as long as the DLLs files are the same "flavor."

I have no experience with the Access Run-Time component, but if there is a way to check it for broken references, I might look there first. There is also a way to have Access applications check their own references. You can try to step through Access.Application.References (a collection of reference objects) that includes such things as the file reference, the "broken" flag, and a couple of other properties. If you were unsure of having valid references, a little "For Each" loop that somehow outputs that collection to something you could call up using a surreptitious method (like double-clicking on what is normally a passive control) could help you validate what should be there.

I have asked the question regarding 32-bit and 64-bit, and I am told that all of our PC's are 64-bit (please bear in mind that I haven't seen these with my own eyes however); I know for sure that my work laptop is 64-bit, as are all of my machines at home.

As far as I know, the runtime environment doesn't allow you to step in and see what is going wrong - it shows only forms, so even tables/queries cannot be got at - ordinarily, this is the ideal solution as it keeps curious fingers at bay.

The 2013 runtime versus 2010 runtime thing is bugging me however -- I am pretty sure that I installed 2013 runtime on a machine a while back, thinking I was going for the most up to date version, and I am pretty sure that it refused to work point-blank.

I suppose the only way I will know for sure is to use a PC that I can get at as a guinea-pig and try it out?

 

[pbaldy]

Thank you - checked that too, and no they are not SP1; to quote the IT guy, they are just "plain old straight 2010, with only the basics like Word, Excel and Outlook"

But SP1 is just a service pack, not a special version. If they downloaded the runtime after SP1 came out, it may be SP1. SP1 could also get installed via Windows Update.

 

[pbaldy]

Oh, and I have a bunch of computers (32 & 64bit) with the 2013 runtime happily running apps I create with 2010 (32bit Access).

 

[fat controller]

Cracked it!

I hi-jacked my daughter's PC (much to her disgust!) and ran through various configurations of 2010 and 2013 both 64 and 32 bit, and was able to recreate the problem. In doing so, I have discovered that I was actually wrong - whilst my PC is 64 bit, my Office 2010 is 32 bit (home machine) - - - the Office 2013 that I had was 64-bit, but I resorted back to 2010 as some PC's at work were baulking at the newer files.... anyway, that is irrelevant really.

I was able to recreate the issue on her PC with a 32-bit version of the runtime environment, then I installed a service pack (SP2) which instantly resolved things!

So, anyone having similar problems, there is a good chance that SP2 will sort your problem - for convenience, here is a link to it

Thank you to you all for contributing and coming up with different suggestions - that is what I love about this forum, everyone willing to pitch in and give ideas to try.