ADO 32-bit/64-bit Incompatibility
I have been developing an application on 64-bit Windows with 32-bit Access for quite some time without problem. Until last week....Now, when I distribute the application to the users (who are running 32-bit Windows with 32-bit Access), any code that includes ADO blows up. If I open the database on any user's machine and change the ADO reference, all works perfectly. I know that I could fix this problem by changing to late binding, but this is not an option since there are hundreds of places where I use ADO.
What do you mean by "change the reference"?
What are you doing with ADO? Are you just opening basic connections and recordsets? If so, then make sure to use the lowest version of ADO listed on your machine before deploying. This will (sometimes) help with that issue.
What are you doing with ADO? Are you just opening basic connections and recordsets? If so, then make sure to use the lowest version of ADO listed on your machine before deploying. This will (sometimes) help with that issue.
ASKER
The information is helpful, but when I go to KB983246, I only see 64-bit downloads. The users' machines are all 32-bit Windows 7. Where can I get the fix for the 32-bit machines?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I am currently using Early Binding. I use ADO to execute stored procedures, passing them parameters. I also retrieve data using recordsets (primarily based on views).
You could use any version of ADO for that.
I'm not sure if the Windows 7 problem is your trouble or not, but it's worth looking into.
I'm not sure if the Windows 7 problem is your trouble or not, but it's worth looking into.
<<I know that I could fix this problem by changing to late binding, but this is not an option since there are hundreds of places where I use ADO. >>
And that would stink to because while it would work, late binding is a performance hit of 10-15% besides loosing intellisense when you develop.
If you do need to change, Rick Fisher's Find & Replace would be helpful with that:
www.rickworld.com
Well worth it if you don't own it (and it's cheap too!).
<<You could use any version of ADO for that. >>
I would try using an earlier version and see if it flies like LSM suggested.
JimD.
And that would stink to because while it would work, late binding is a performance hit of 10-15% besides loosing intellisense when you develop.
If you do need to change, Rick Fisher's Find & Replace would be helpful with that:
www.rickworld.com
Well worth it if you don't own it (and it's cheap too!).
<<You could use any version of ADO for that. >>
I would try using an earlier version and see if it flies like LSM suggested.
JimD.
ASKER
I tried using ADO 2.0 and the same problem occurred. I know that it's a Windows 7 SP 1 problem. If I compile an Access application using Windows 7 SP1, that application CANNOT be run on machines without SP1.
Hi,
I've had the same issue and went to a DAO solution. I am trying to start a discussionj on this issue so you might look at this thread.
https://www.experts-exchange.com/questions/26958211/SQL-Server-Data-Connectivity-Best-Practices-for-MS-Access-VBA.html?cid=1416
Regards,
Bill
I've had the same issue and went to a DAO solution. I am trying to start a discussionj on this issue so you might look at this thread.
https://www.experts-exchange.com/questions/26958211/SQL-Server-Data-Connectivity-Best-Practices-for-MS-Access-VBA.html?cid=1416
Regards,
Bill
ASKER
This did not solve my problem because the problem really doesn't have a solution. The "solution" contained a link to an article talking about the problem, and indicating that it hasn't yet been resolved. Just knowing this was helpful.
http://www.utteraccess.com/forum/Avoid-Windows-7-Sp1-t1962370.html
The content in that link came up in an MVP discussion recently ... and your situation sounds possibly similar ...?
mx