Getting the official Microsoft word on something?
-
I'm pretty sure I know the answer to this but...
I'm developing a 64-bit app that interfaces with Access databases, which works fine with the 64-bit ACE drivers. However, due to some inexplicable co-mingling, you can't have 32-bit and 64-bit Access drivers existing on the system without 'tricking' Windows. This also works fine, until Windows update 'fixes' your trickery, forcing your 32-bit Office installation to repair itself and break your 64-bit drivers.Some solutions are obvious, but stupid (switch to SQL, turn off Windows Update, force users to use 64-bit Office...) and I'd like to get Microsoft's official recommendation. They're going to make me pay for that aren't they?Kyudos wrote:
you can't have 32-bit and 64-bit Access drivers existing on the system without 'tricking' Windows
I haven't found that to be true. But maybe because our servers don't have Office installed? Do you have proper servers? Without Office?
-
Kyudos wrote:
you can't have 32-bit and 64-bit Access drivers existing on the system without 'tricking' Windows
I haven't found that to be true. But maybe because our servers don't have Office installed? Do you have proper servers? Without Office?
-
It's a consumer app - it'll be on people's machines with their whatever-version of Office. If they happen to have 64-bit Office (unlikely) it'll all work OK, but if they have our 64-bit plugin, and 32-bit Office (more likely) its a potential problem.
Then it sounds like it's up to the customer to be sure it runs. Not your problem.
-
Then it sounds like it's up to the customer to be sure it runs. Not your problem.
-
Maybe it does not work, but why do you not release a 32 bit version of your app for people running 32 bit office with 32 bit drivers?
Within you lies the power for good - Use it!
It's a plugin - if they have a 64-bit version of the host app, they need a 64-bit version of our product. Of course, we will have a 32-bit version too, but forcing the user to acquire a different 'bit-version' of the host app isn't ideal. Inevitably they will tend to ignore the requirement, and then complain about our app 'not working'. It would all have been academic if Microsoft hadn't made their drivers mutually exclusive...
-
It's a plugin - if they have a 64-bit version of the host app, they need a 64-bit version of our product. Of course, we will have a 32-bit version too, but forcing the user to acquire a different 'bit-version' of the host app isn't ideal. Inevitably they will tend to ignore the requirement, and then complain about our app 'not working'. It would all have been academic if Microsoft hadn't made their drivers mutually exclusive...
What if you determine the bitity on install and then make sure the correct plugin version is used?
"A property doesn't have to be a Property to be a property." - PIEBALDConsult
-
What if you determine the bitity on install and then make sure the correct plugin version is used?
"A property doesn't have to be a Property to be a property." - PIEBALDConsult
-
There is no problem matching bitity of host and plugin - the problem arises when that bitity is not matched by the installed version of Office. Not many people use 64-bit Office, so people using 64-bit host are likely to have 32-bit Office.
Shouldn't you be able to find out which version of Office is installed, too?
"A property doesn't have to be a Property to be a property." - PIEBALDConsult
-
Shouldn't you be able to find out which version of Office is installed, too?
"A property doesn't have to be a Property to be a property." - PIEBALDConsult
