missing reference to mso.dll with some access 2010 machines when running ade, adp correct

[Yasser]

I have an application compiled on access 2003 on XP.
It is installed on a server and there is a mechanism that copies on the client side the ade file when it detects a version change.

Some new machines are running access 2010 runtime with Windows 7 64 bits and 32 bits office (did not verify access runtime)


Most of those machines are running fine but some have a missing or broken reference to mso.dll version 2.3 (dll for office 2003). The error comes from a function that checks all the references during the initialization of our app. Mso.dll is located on the problematic machines under office 14 (office2010) and found under registery.

When looking closely at the machine, I am able to run the adp file of the exact same version with no error while the ade gives the error.

Any idea what could cause this error or what are the possible solutions?

Thank you

[ItsMe]

...server and there is a mechanism that copies...

I would guess an ade file would run fine as long as the machine that compiled it was using an earlier version of Access (I think you could still do this with A2007??). After the ade file is compiled, make sure another machine does not try to open it.

According to Microsoft, adp files can still be opened with A2010.

[Yasser]

But some machines with access 2010 do run fine and some don't.
So I would guess that there is something specific with those problematic machines!

[ItsMe]

Are they all running ade's. Maybe one or two are running the adp?

If one machine is working and another is not, you are going to have to find out what is different. The only other thing I can think of is that two machines tried to open the same ade or adp file. Each machine needs to have their own front end files, locally or over a network (as long as it is their own). If two battle for a single file, one machine might work when the other does not. Or, both will not work because the file will stop working.

[Yasser]

Each machine has its own front end Ade file copied locally by our mechanism so no battle for files possible.

Adp file was just a test that i did myself as an admin but cannot be accessed by regular users.

But now that I think of it, the adp was executed while still on the server while ade file is copied locally on the machine!!

Could this mean something?

[ItsMe]

...But now that I think of it, the adp was executed while still on the server while ade file is copied locally on the machine!!
...

This is something I avoid doing. I avoid it because I have been able to break files on purpose. I have used two machines to open a single file over a network. The two machines are different hardware, OS, version of Access. Eventually, the file breaks. I have done this with mdb files but have not tried it with accdb files. FWIW

[Yasser]

I did some additional tests and here is what I found.

On the majority of the access 2010 machines, adp and ade files work fine.

On 6 machines:
Adp files work fine.
Ade files created with access 2003 give mso.dll missing reference error
Ade files created with office 2010 works fine.

But we need to keep files compatible with both 2003 and 2010.

Not sure why those 6 machines that were installed with same packages and image as the rest of the working machines have this problem

[ItsMe]

I really don't have an answer. I would think that references to Microsoft Office would update themselves when opening the ade or adp. Perhaps there is a nuance between the executable and the adp. Beyond that, all I can do is guess why the symptoms between different machines running Office 2010. So, I will guess some machines had an earlier version of office installed and their registry has the dll registered with the old path, avoiding the error.

But, it sounds like you have all the clients working. I go through the trouble of producing version specific apps regardless. So, your situation does not seem so bad to me. I mean, now that your clients are all working.

[Yasser]

I guess you are right.

Thanx a lot for your answers

[ItsMe]

You bet. And I forgot to mention that you could change VBA code from early binding to late binding in an effort to avoid the error. Maybe you have some code that uses early binding to automate Outlook or something.