code to detect and run access on both 32 bit and 64 bit machines 3

[Lhuffst]

I have a database that, when deployed, will run on both 32 bit and 64 bit machines. It runs fine on my 64 bit but I throw errors on the 32 bit machines. Through the various support articles I've read, it seems to do with the active x files but I haven't run across any explanations or samples of how to account for both in the program.
Any suggestions?
Thanks
Lhuffst

 

[Lhuffst]

just realized that I'm actually running a 32bit version of access 2010 on my 64 bit pc. So why would I get errors when I run the same system on a customers pc that is 32 bit?

 

[lameid]

Microsoft likes to issue security patches that break things from time to time. One thing to do is identify exactly what control and file is not working and compare the versions on the two machines and identify why there is a difference. It could be your machine is fully patched and the client is not.

Another thought, nothing is wrong except for the compiled code. Use the decompile command line switch at the client and recompile (some compiled code tends to stick around without doing things).

Lastly if you post exactly what you are using and how, someone may know your specific issue.

 

[Goondu]

Please refer to this MS site for detecting 32 or 64bit.

https://msdn.microsoft.com/en-us/library/office/ee691831(v=office.14).aspx

You'll need this code to run first. It will detect the 32 or 64 bit APIs.

You'll also need to recode all your APIs if you need to run 64bits APIs. I think you have to recode all your APIs if Windows is 64bits. Also please of the issues with some of the variables of APIs will also be different, they might not work in 64bits. Test all your APIs before you deploy.

Also here if you need further help.

https://msdn.microsoft.com/en-us/library/ff700513(v=office.11).aspx

 

[Lhuffst]

Thanks to lameid and goondu. I have to work on another project for now so it will be a few days before I can review this.
Lameid the error seems to be with mscomct2.ocx (at least that's the one I get now).
Thanks again

 

[lameid]

At the top of Goodndu's article it talks about that .ocx... that it is installed by Office and only works with 32 bit office (doesn't work with 64 bit).

So back to my original point on finding out why it is different... I'd try fully patching the problem machine assuming it is not or compare your installed updates versus theirs. Read up on the updates that are different or apply the ones they are missing.

 

[lameid]

I think you have to recode all your APIs if Windows is 64bits.

False if you have 64 bit Windows, you CAN install 64 bit office but can still install 32 bit office. If using 64 bit office you have to handle the 64 bit api's otherwise 32 bit office makes 32 bit calls which are generally handled fine by windows although with more overhead which you probably won't notice as 64 bit machines are usually higher end.

 

[Goondu]

False if you have 64 bit Windows, you CAN install 64 bit office but can still install 32 bit office. If using 64 bit office you have to handle the 64 bit api's otherwise 32 bit office makes 32 bit calls which are generally handled fine by windows although with more overhead which you probably won't notice as 64 bit machines are usually higher end.

As I recalled, you still need to recode some of the 32bit APIs for Windows 64bit.

I can't recall which API, but I can remember you still need to recode some, not all. If you don't, you'll error or just that your API don't work correctly. That was about 6 years ago.

 

[strongm]

>recode some of the 32bit APIs for Windows 64bit.

That'll come as a surprise to Microsoft.

 

[lameid]

Some of the datatypes you reference sound SQL server vs. Access. Are you using an Access Database for your data?

In any case I would probably use functions like cdbl to convert everything to doubles, do the math and convert / round it back to the final datatype. That is assuming that a double is the datatype that doesn't mess up the calculation which it seems to be by your description.

 

[Goondu]

It's not a surprised. The code by Ken Getz for example, the file dialog box "comdlg32.dll".

Type tagOPENFILENAME
lStructSize As Long

Function ahtCommonFileOpenSave( _.........
......
With OFN
.lStructSize = Len(OFN)
-----------------------------------------------

I had to change it to

.lStructSize = LenB(OFN)​

get it to work in Windows 64 bit. Unfortunately, I don't recall anymore changes needed. I have to dig up my old files to see what was the problem and changes.

You can try to use Ken Getz File Dialog Function to see the problem. I'm not sure if MS have resolved the issue.

This issues were not related to my other post on Tax calculation.

 

[strongm]

That's nothing to do with the API and everything to do with the difference between VBA's Len and LenB functions. Basically, LenB has always been the better option for returning the size of structures since it includes any byte alignment padding (and space allocated to fixed strings). And it isn't something that Microsoft are going to resolve since there is nothing that actually needs correcting.

32bit VBA will happily use the 32bit API without any changes. If, however, your VBA platform is 64bit (e.g Office 64), then you are no longer calling the original 32bit API (nor the 32bit instruction set), so yes you'd need to change your VBA code to take into account 64bit data types (which versions of VBA prior to 7 did not include) - but that's because you're now running 64bit code, not 32bit code.