problem accessing the correct kernal32.dll (32 vs 64bit) from a vb.net 2005 app...

Hi there, I have a bit of a situation with an in-house 32bit app we have. We have vs.net 2005 installed on an Xp Pro SP3 machine, and has the .net framework 2.0 installed. We used to have a full time developer but he has left the company and now I am supporting these apps. I do not want to touch his development PC as he had it set up just so...

I come from an app dev background and have developed some vb apps so I'm not a complete newbie but it's not what I did a lot of anymore, till now! There's the background for ya...

So, we have this custom app which uses an ODBC (32bit) Pervasive SQL driver to access accounting data from our Business Visions accounting database. It has worked fine for years - as all of our machines were 32bit systems. Enter the first 64 bit system that needed to have this particular functionality available for the end user. When the user attempts to access this functionality, the app fails miserably. I am getting the following error when trying to open the Pervasive SQL dataset... below is the line of code that fails. This code is located in a function that attemts to validate the connection to the accounting data using the odbc connection...

Dim objConn As Microsoft.Data.Odbc.OdbcConnection


The error I get is... "Unable to find an entry point named InterlockedIncrement in DLL kernel32.dll"

Now, I did some research and found a couple of things to try... 1) I thought that maybe Pervasive SQL might have a 64 bit version of their driver -they do not. 2) One fellow said to use the "system.data.odbc.odbcconnection" class instead of the "microsoft,data.odbc.odbcconnection" class but that failed with a "The specified DSN contains an architecture mismatch between the driver and the application." .

What I think is happening after researching a little further is that on 64 bit systems, the 64 bit version of "kernal32.dll" is stored in the c:\windows\system32 folder while the 32bit version of it is stored in a different folder (c:\windows\sysWOW64). Apparently through 'redirection", an application is supposed to be loading the appropriate 32 or 64 bit dll's from either system32 or syswow64 depending on whether the app is 32 or 64 bit. I do not think this is happening in my case. I suspect it is loading the 64bit version of kernal32.dll from the system32 folder and in that version, the method interlockedincrement does not exist and has been replaced by interlockedincrement64 - which if there had been a 64 bit version of the Pervasive odbc driver, likely would have called that 64 bit function instead and all would have been fine!!!

I also discovered that there is no "compatibility mode" settings in vs.net 2005 which some folks referred to having to set in your project in order to have your 32bit app use the correct folder to load the 32bit dll's...

Does anyone know what I can do? I am assuming I am going to have to explicitly load the 32 bit kernal32.dll file from the c:\windows\syswow64 folder correct? How does one go about specifying that in a vb.net 2005 project or if anyone has any other ideas, please let me know...


Thanks!

I'm afraid that there isn't much you can do about this. Do you guys absolutely have to run a 64 bit version of Windows ? If it were me I'd recommend re-installing a 32 bit version of Windows.

Well, I wouldn't think that's a viable solution. I'd just love to have 12GB of memory sitting there and unreachable.

Try changing it from Microsoft.Data.Odbc to System.Data.Odbc and see if you still have the issue.

Quote:

---

Originally Posted by MattP

Well, I wouldn't think that's a viable solution. I'd just love to have 12GB of memory sitting there and unreachable.

Try changing it from Microsoft.Data.Odbc to System.Data.Odbc and see if you still have the issue.

---

I've never seen a database client that needs 12 GB of memory. A database client is nothing more than a souped up display terminal. Its the server that needs all the power. If I felt there was a better solution, I would suggest it, but my own experience with database applications and 64 bit OSes always lead me to conclude that the ability to reference more memory is not worth breaking your most used app for. If the use of a database app is one of many things you do with your PC then I can support fighting it out on an x64 for the sake of your other applications that might benefit from more memory.

Thanks guys, I certainly don't want to shy away from migrating to 64 bit systems as I have to replace PC's just because of this. There has to be a solution - has to be! I did try the second solution above re: using "system.data..." instead of "Microsoft.data..." but as reported in my initial question, I got an error there too... My biggest problem is that Pervasive does not provide a 64bit driver - otherwise I'd likely be ok. Maybe I will see if I can move this user over to a 32bit system for the time being... question though, if I migrated from vs.net 2005 to a more recent version, would I then be able to overcome this issue by setting the "compatibility mode"?? it's likely time to migrate to a newer version anyway... Just curious...

Hmm...I see that you've already changed from Microsoft.Data.Odbc to System.Data.Odbc. Looking into this problem I came across this post: http://dandarache.wordpress.com/2011...en-using-odbc/.

Here's a link for Visual Studio 2005 for setting the target CPU: http://msdn.microsoft.com/en-us/libr...(v=vs.80).aspx

PS... it's definitely not a memory issue that we had to go out and buy a 64 bit PC for. We needed a new PC and that's what we got. It runs everything else just fine (Accounting Software, Office 2010 apps, the rest of our custom VB stuff etc... etc... - Just this one process that needs to access BV data using the pervasive 32 bit driver causing grief... I'll have to move her to a different PC for the time being but I hate being told there is nothing that can be done, there's usually always some sort of workaround!! Sigh.....

Wait, before you do that, might I suggest a middle of the road solution. You can try using a virtual PC that hosts a 32 bit version of Windows. That way, she can have her cake and eat it too....in a manner of speaking ;)

Ya, that's a potential solution as well and might definitely be something I could try to set up. Right now to get the job down she has to logon to a win2k3 terminal services session (which we use mainly for remote access to our systems) The app runs fine on a 32bit windows 2003 TS session. We now have server 2008 R2 (64bit) but I have yet to configure any remote desktop services. I suspect I'll still have the same problems with them though as they will be 64 bit Windows 2008 R2 sessions... I am unsure if win2k8 RDS will allow the configuration of an OS (ie, windows 7 32 bit) that is different than the server os... Do you have any idea?

You can try to use a try statement in the program to have it use the 32 bit kernal32.dll and point to where it is supposed to be, and in the catch portion have it point to the appropriate kernal for a 64 bit system.

Quote:

---

Originally Posted by clankster

Ya, that's a potential solution as well and might definitely be something I could try to set up. Right now to get the job down she has to logon to a win2k3 terminal services session (which we use mainly for remote access to our systems) The app runs fine on a 32bit windows 2003 TS session. We now have server 2008 R2 (64bit) but I have yet to configure any remote desktop services. I suspect I'll still have the same problems with them though as they will be 64 bit Windows 2008 R2 sessions... I am unsure if win2k8 RDS will allow the configuration of an OS (ie, windows 7 32 bit) that is different than the server os... Do you have any idea?

---

Hmmm....it may be possible to use Remote Desktop/TS with the virtual environment but I can't be certain. Looks like you have your work cut out for you ;)

Quote:

---

Originally Posted by claws135

You can try to use a try statement in the program to have it use the 32 bit kernal32.dll and point to where it is supposed to be, and in the catch portion have it point to the appropriate kernal for a 64 bit system.

---

Actually, he can't do that as the problem is in the ODBC driver itself.

So the problem is the 64 bit ODBC driver itsself not working on the 32 bit application, because its looking for the 32 bit ODBC Driver.
Sorry i wasent quite understanding here, but hopefully now i grasp the concept slightly more.
Make sure you configure the 32 bit ODBC Driver here: C:\Windows\SysWOW64\odbcad32.exe
I also found this, not sure if it will help you or not.
http://support.microsoft.com/kb/942976