Unanswered: Access Runtime Conflicts with Native Access
Runtime Conflicts with Native Access
I plan to use XP Access Developer to create an application for distribution in the commercial market. Customers who purchase the software may have XP but more likely will have earlier versions.
I am aware that there is a conflict if a XP Runtime is installed on a PC with earlier versions of Access and databases built in these earlier versions. The conflict apparently derives from the registration of the Runtime. When it is registered on a PC that already has an earlier version of Access installed, then there are two possible Jet engines that might be invoked against an Access file. I also understand that the registry will continue to use the same jet engine until explicitly told to use a the other one by providing a full filepath to it.
Thus, my understanding and partial experience is a scenario like this. You have Access97 installed then you purchase and install a XP Runtime application. After running the new application, if you attempt to open an A97 dB, an error is returned (I cannot remember if it is an offer to convert the dB to a newer version or another kind of error). Or if you open the Access97 Jet engine explicitly, then next attempt to open the runtime will be by that A97 engine and will return 'unrecognizable format".
I believe most of the above is correct, but it has been so long since I worked with XP Developer, I would not state perfect accuracy. My question is, has anyone gotten around this problem and if so, how did you do it?
The Only workaround I've found so far is to create shortcuts for the databases instead of opening them directly. Point the shortcut to the correct version of access with the full path of the database file as a startup parameter.
Note: you might need to make the strAccess97Path a dynamic variable that is set by the End-User. You could probaby store it in a separate table & reference it in the above code.
In essance what this will do is Open Access97 everytime you quit AccessXP & reset the .mdb associations. Since the Shell command is set to open the Access97 db in a hidden state the end user would only see the Access97 Splash screen & the startup form would quit out of Access97.
Most interesting! I do see the logic and possibilities as I already have a couple of temporary dBs associated with the application.
I don't know all the version nuances but I suspect that A2K & A02 & A97 are not prone to talking well with each other. Although I have not looked at your proposed approach carefully, I suspect that a call could be made to both of the earlier versions. A returned error could just be trapped.
I have discussed this with Microsoft as a point in a XP Developer 'case' but they cut me off without providing a good solution or interest in their own making a "fix".
I always assumed that there are a lot of Access applications being created and sold but with a glitch like this, one wonders. I'd like to see some stats on Access commercial software sold.
Like your approach I wonder if system calls to the Registry could provide knowledge of their existence and filepath. Then use your function. (By the way, the code is cool! Thanks!)
This problem has been frustrating me for over half a year since I discovered it. I feel that Microsoft let this slide for 3 versions, possibly from 2.0. The XP Developer's User Manual does not have an Index much less than an extensive chapter or two on troubleshooting. But I digress.............