I have developed an MS Access app which has been successfully implemented on several machines as a MS Access runtime 2007 .accdr install. It successfully runs on combinations of XP and Vista and Office 2003 and 2007. However, I installed it on one machine running XP Pro and Office 2003 (including access 2003). It runs OK but when an existing Access 2003 .mdb is opened no functions work in the .mdb app. This was traced to the Microsoft Acces 11.0 Object Library (MSACC.OLB) being replaced by the runtime 12.0 Object Library (OL). Replacing the 11.0 OL caused the Runtime app. to cease working.
I tested this on one of my own machines running XP Pro and Office 2003. After installing the runtime app. when I loaded the MS Access 2003 .mdb, MS Access ran a short install process to, presumably, change the 12.0 OL back to the required 11.OL. Both apps then ran comfortably together.
Could someone please let me know what is happening when co-existing .mdb and .accdr apps and why the two apps can happily co-exist on my machine and others but not on the original target machine. Could this be that the userid needs amdinistrator rights to run the short install process when the Access 2003 .mdb is started?
I don't know whether this helps but I found some other interesting facts when I tested on my machine:
1. If the runtime app .accdr is started first, the .mdb app, when started, runs within the runtime environment
2. If the .mdb app is run first, the .accdr happily starts without fuss and the .mdb app continues to run happily
3. If the last app run is the .mdb, all subsequent restarts of the .mdb start without fuss. However if the last app run was the .accdr, then the first start of an .mdb causes the short install process to run. All subsequent restarts of the .mdb start without fuss.
Sorry this is lengthy but I would appreciate a solution or at least knowledge of how the environments inter-operate. There's nothing on the web; at least I couldn't find it......
Thank you in advance.....
Start Free Trial
