distribution issue

[Jen0dorf]

Hi

I create an accde file using access 2010 v 14.0.7162.5000 32 bit which runs perfectly.

I downloaded the access 2010 32 bit runtime from micrsoft.

I went to my test windows 10 system - no access and installed the runtime and then ran the setup file it all worked.

The user has come back to me and on their windows 7 home premium machine they get the error

"The database cannot be opened because the VBA project contained it it cannot be read. The database can only be opened if the vba project is deleted...."

Haven't got a clue what to do

Is it a runtime issue? or a database issue or even an issue with the runtime version.



Appreciate any help

thanks

Ian

[ItsMe]

It sounds like there is a broken reference. Do you have a list of references that you made in the original Access file?

[Jen0dorf]

Hi

I feel this could be a homer moment

doh!!

whats a broken reference??

IAn

[ItsMe]

Did you create any references via the VBA editor using Tools>References?

[Jen0dorf]

Hi

no till your last post I had never come accross references

if I open the database and select the vb editor
in references I have

visual basic for applications
microsoft access 14 object library
ole automation
Microsoft office 14 database.....


If I closethat window and go to tools compile is greyed out So I assume this means I have not used and VB?

I am doing this on the master full version not of the run time and on the development PC on which the run time does work

thanks

Ian

[ItsMe]

If I closethat window and go to tools compile is greyed out So I assume this means I have not used and VB?

No, not necessarily. When you write code, you are writing in human language. Then, the human language needs to be compiled in a way that the Run Time engine can understand it. You use the compiler to compile the human code to a syntax that the Run Time can understand.

In general, and I do not know the specific names that Access uses, you have Human Code that you write. Then, you compile this to an Intermediate Language. The intermediate language is something that the Run Time engine understands. When a User clicks on an executable for the first time, the Run Time will compile the Intermediate Language compilation into another language, Machine Language. The final Just In Time compilation is specific to THAT machine. The Run Time takes into consideration what the machine is built with and what applications, O.S., drivers, etc. are installed on that machine.

So, if you go to Debug>Compile Database, and Compile is greyed out, this means that there is no new VBA code that needs to be added to the Intermediate Language compilation.

The best indicator of the existence of VBA is to look at the Project - Database window. This window is usually open and to the left of the VBA editor/IDE, by default. If there are any Custom Classes, Standard Modules, or modules that are associated with a form or report, they will be listed there.

Having said all of that, If you do not have any VBA, there is not really any sense in making an accde. In general, an accde is the same as an accdb except, an accde does not contain any VBA. All of the VBA has been removed and the Run Time will look to the Intermediate Language compilation. There are a couple of other nuances with an accde, but the removal of the Human Language is the major thing. If you open an accdb with a machine that only has the free RT version of Access, it will treat it the same as an accde. It does this because it does not know how to interact with the VBA and the tools that are exclusive to an accdb and the full version of Access.

BACK to the original Error Message:
You seem to have a conflict with versions. I am going to guess this has something to do with a Macro that was created using a specific version of Access that is not compatible with the 2010 RT. Another consideration is that you are not using a clean copy. I will go to a development machine with the oldest version necessary and create a new file and import items into the new file. After the Import process I will run one compact and repair and leave it alone, distributing copies of that.

I would determine if there is a need for creating an accde. Then I would determine what version of Office is installed on the W7 machine. In a perfect world, you would install the same Access RT version as the version of Office currently installed. However, this is not mandatory.

I seem to remember you creating a front end using 2013 and having issues with an accde. If I was developing an application with A2013, I would make sure that each machine had the 2013 Run Time installed and that I created a shortcut for my app that made sure the Start In was defined as the 2013 version of the RT.