Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Sunday, September 18, 2011 4:21 AM
I am running W7 32 bit ultimate with net 2010 development
I have an app I want to distribute which works fine on XP & W7 32 bit, but fails on being installed on W7 64 bit, I believe, although not 100% certain the error I am getting: "Unknown Cause; 3706 > Application-Defined or Object-defined error" is related to ADO
Whilst I have no need to fix my own W7, how do I incorporate in the distributed msi, whatever is required for 64 bit if that is the problem.
Or what Instructions are need on the users W7 64 bit pc to resolve this?
Thanks for any help
All replies (22)
Tuesday, September 20, 2011 12:05 PM âś…Answered
If you don't have SP1 installed on your Windows 7 machine then there is no compatibility issue with Classic ADO. It's only if you are developing on an SP1 machine and deploying to prior versions of Windows where there is a problem.
You will have to test your app on a 64-bit Windows machine in order to verify whether compiling to x86 (32-bit) resolves your issue. I don't think you really need a separate installation in this instance since the app will be running 32-bit on both 32-bit and 64-bit Windows.
Paul ~~~~ Microsoft MVP (Visual Basic)
Sunday, September 18, 2011 12:18 PM
Not my expertise, but you should be creating a separate deployment package for x64. The two are incompatible. Here's a top-level link on the subject at MSDN: http://msdn.microsoft.com/en-us/library/ms165428.aspx
Sunday, September 18, 2011 9:00 PM
Thanks for your reply, it may appear that the problem is not 64 bit, but rather W7 sp1 to either 32 or 64 bit
After doing some hours of web searching I have come across this
It's worth reading if only for comments about Microsoft.
I still don't know which way to resolve this issue, any other comments most welcome.
Monday, September 19, 2011 1:29 PM
If you are developing an app with Classic ADO under SP1 of Windows 7 and deploying to down-level versions of Windows you have to use the Microsoft ActiveX Data Objects 6.0 BackCompat Library. Apparently Microsoft broke backward compatibility with the ADO library in SP1. Note that Classic ADO is already installed on current versions of Windows and does not need to be deployed.
Also, make sure your app isn't using components that are limited to 32-bit. If this is the case then you will want to compile your app with the x86 Platform option (Build...Configuration Manager).
Paul ~~~~ Microsoft MVP (Visual Basic)
Monday, September 19, 2011 2:49 PM
In short, you need to set your project build platgorm to x86 instead ANY CPU. That can let you application work in the x86 mode always, including in the 64-bits OS.Bob Bao [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Tuesday, September 20, 2011 4:10 AM
Thanks to Paul & Bob for contributions, my development machine does not have SP1
My app is intended to be available on the web, so I have no idea which Sp anybody is using, currently I have 2 versions for 32 bit, one for XP & one for Vista&W7
My expertise in VB leaves a lot to be learned & some suggestions raised are not familiar to me.
Could somebody enlighten me on which path to take for creating a 64 bit W7 version:
1. is setting the build platform to x86 all I need to do or:
2. do I have to create a separate build version for 64 bit as suggested by Dig Boy
Not my expertise, but you should be creating a separate deployment package for x64. The two are incompatible. Here's a top-level link on the subject at MSDN: http://msdn.microsoft.com/en-us/library/ms165428.aspx
And does this resolve the issue for ADO on users machines that have installed SP1
Tuesday, September 20, 2011 5:13 AM
Somehow I've the idea that you use a non supported VB version, can you tell us what version of the Framework your question is about?Success
Cor
Tuesday, September 20, 2011 5:20 AM
I am using net 2010 professional with a build of the app using net framework 4
Tuesday, September 20, 2011 6:11 AM
VS2010 Pro version, with .Net 4, why you still use the ADO? Why not to use ADO.Net to develop your application?
Bob Bao [MSFT]
MSDN Community Support | Feedback to us
Get or Request Code Sample from Microsoft
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Tuesday, September 20, 2011 6:27 AM
Thanks for replying, my app was developed 10 years ago in vb5 & migrated to Vb6, net 2005, net 2008, now net 2010
i am not sure how ADO.net would be deployed in my app, is it a simple conversion or a whole new way of needing to re-write hundred of lines of code?
Tuesday, September 20, 2011 6:32 AM
Also I am using an Access97 database which really is just a table of data, could just as easily be a delimited text file, theres nothing fancy about the data storage, just huge amounts of code in my app to manipulate how the data ends up in the table
Tuesday, September 20, 2011 7:12 AM
If I read your replies than I get the idea you are simply pushing your problems forward however you more and more reach the ravine and just some more steps and you fall in that.
Try to redesign your application like is adviced by more in this thread.
If you create first your own DataBase Layer than replacing your old parts will be easier than you think
However, create that first don't try to change row by row complete, create first the likewise methods.
To do that you can add a new Class Library Project to your solution.
Be aware a recordset is the same as a datatable, not like a dataset which is in fact a binder for datatables (recordsets in your old vocabulaire)
Success
Cor
Tuesday, September 20, 2011 7:28 AM
Thanks for your reply, Cor
As my app is available for download from the web & has been for some time, my options seem to be for it only to be available for 32 bit XP & W7 which work fine.
I have only just had a user find the problem with 64 bit
Seems I will have to advise of it's limitations until I can resolve this issue which according to you is a monumental task
Will have to leave forum for 20 Hours
Tuesday, September 20, 2011 11:56 AM
Thanks to Paul & Bob for contributions, my development machine does not have SP1
My app is intended to be available on the web, so I have no idea which Sp anybody is using, currently I have 2 versions for 32 bit, one for XP & one for Vista&W7
My expertise in VB leaves a lot to be learned & some suggestions raised are not familiar to me.
Could somebody enlighten me on which path to take for creating a 64 bit W7 version:
1. is setting the build platform to x86 all I need to do or:
2. do I have to create a separate build version for 64 bit as suggested by Dig Boy
Not my expertise, but you should be creating a separate deployment package for x64. The two are incompatible. Here's a top-level link on the subject at MSDN: http://msdn.microsoft.com/en-us/library/ms165428.aspx
And does this resolve the issue for ADO on users machines that have installed SP1
That suggestion was made before you found what is really the problem regarding no backwards compatability. Paul has suggested that the ADO 6.0 Backward Compat Library may resolve the issue for you... have you tried out his suggestion yet.
As for the need compile a x64 binary -- that depends on what's in your app. If you are using unmanaged code (likely no if you are writing in VB) or if you are using COM objects (yes, if you are using ADODB) then there is the potential for problems. But .NET on a x64 machine also has a 32 bit install of .NET beside it so typically the apps run just as fine. Here is an article that provides some context: http://www.hanselman.com/blog/BackToBasics32bitAnd64bitConfusionAroundX86AndX64AndTheNETFrameworkAndCLR.aspx
Tuesday, September 20, 2011 12:07 PM
Thanks for replying, my app was developed 10 years ago in vb5 & migrated to Vb6, net 2005, net 2008, now net 2010
i am not sure how ADO.net would be deployed in my app, is it a simple conversion or a whole new way of needing to re-write hundred of lines of code?
It's a complete re-write. Classic ADO and ADO.NET are significantly different.Paul ~~~~ Microsoft MVP (Visual Basic)
Wednesday, September 21, 2011 5:19 AM
Thanks to all for contributions and suggestions, my real problem now is that I do not have a 64 bit system to test on, I have to rely on feedback from a friend who has W7 64bit.
So, my next move is to compile using X86 cpu and forward a version to my friend to try out, thanks to Paul
to answer Dig Boy, yes I am using com object ADO
I will endeavour to get back asap, meanwhile I hope the above is useful to others with same problem.
Wednesday, September 21, 2011 6:24 AM
Just tried to compile with X86 and got the following problems.
1. could not find the file Project\obj\x86\release\project.exe, yet it never existed before & according to compile properties it says Build output path = bin\x86\release, so what do i have to do to get my project.exe in the folder, surely the compile instruction with the settings appear to be ok & the folders exist, so why complain about a missing project.exe when it should be compiled in the build process?
2. I have DirectoryTreeView as a refernce as a NET reference, yet the compile shows it as an error
3. after finding the above, I reverted back to any cpu and works fine on my pc, however while amending the cpu I noticed in the project properties for compile, there is an advanced compile option, so I looked at that & found that the target framework is NET framework 2.0
this did not make sense to me so I changed it to framework 4, it builds & runs to the first screen but has no directory tree & all buttons/menus will not perform any functions
Should I have 2 or 4 framework in this advanced option & if 4 then why does nothing work & no directory tree?
Wednesday, September 21, 2011 2:33 PM
Can you compile successfully when using x86 and setting the Configuration option to Debug?
I'm not familiar with DirectoryTreeView. Is this a third-party component?
Paul ~~~~ Microsoft MVP (Visual Basic)
Wednesday, September 21, 2011 8:58 PM
No, same problem, cannot locate project.exe in folder, although folder exists, seems it is expecting it to be there although it has never been created before as an x86 build
Directory treeview is a free component replicating windows explorer directory tree
Thanks
Friday, September 23, 2011 2:22 PM
Could you post the exact error message that occurs when compiling?Paul ~~~~ Microsoft MVP (Visual Basic)
Friday, September 23, 2011 8:52 PM
Thanks for getting back to me
My project name is Photo_xplorer
Error 10 Could not find file 'Z:\00-VB_Net\0-Projects-2005\Photo_Xplorer\obj\x86\Debug\Photo_Xplorer.exe' 'The system cannot find the file specified.' Z:\00-VB_Net\0-Projects-2005\Photo_Xplorer\Setup\Photo Xplorer\Photo Xplorer.vdproj Photo Xplorer
I have found a method of replicating DirectoryTreeview which used an old legacy dll from vb5 days, so will have to replace all references to that which could take some time
Thursday, September 29, 2011 5:50 AM
Thanks to Paul I now have it working.
What I did: removed the DirectoryTreeview & replaced it with treeview, compiled under x86, rebuilt my PC with 64 bit & tried it out & it works, so at this stage ADO appears to be ok on W7 64 bit