Converting 32 bt to 64 bit???

[gblack]

I have a user that just switched to 2010. He tried to run my Accde file and couldn't. It seems that he's running 64 bit version of Office 2010.

When I tried to open my 32 bit application... it said I needed to change it to 64 bit. Or words to that effect...

I tried the save database as... but it told me it couldn't compile.

I have looked around and the only thing I found seemed ridicoulsly involved (more than my pea brain could absorb)... is there some "easy" way to convert my split app... so that this guy can use it? Or am I bit out of luck?

Thanks,
Gary

 

[Banana]

First of all, does he REALLY need 64-bit Office? The chance are that he doesn't and would be better off with just 32-bit Office. Microsoft currently recommends against installing 64-bit Office and your user must have went out of his way to get it to install 64-bit.

But assuming there is a legit reason to use 64-bit Office (most having to do with Excel, and next to none for any other programs, actually) then you'll have to update your application to work with 64-bit Access. There are 3 general considerations:

1) If you have linked tables to big databases such as SQL Server, Oracle or whatever, you need to be sure there's 64-bit driver installed on the computer. With SQL Server, it should be already installed (comes with Windows) but this may not the case with other RDBMS if you're use any of those.

2) If you're using any ActiveX controls, you'll have to either disable, remove or update to a control that is 64-bit. This is more serious because there are not always 64-bit replacement. A good example is if you have a TreeView control from MSCOMCTL.OCX. There are no 64-bit MSCOMCTL.OCX so you have no replacement for that and thus your TreeView would not work. You'd probably have to look at third-party ActiveX that is 64-bit compatible if you really wanted to keep TreeView in 64-bit Access.

3) If you have any API functions in your applications, then you have to update the statement. Grover Park George has a blog post about this process here. Hopefully it'll give you an idea of how you can update your declarations.

If your application doesn't have any ODBC linked tables, ActiveX controls and API functions, then it'll work as it is without any modification. It's obviously rare that such applications are not that complicated.

PS: Oh I forgot to mention -- you can't share a *DE file between both 32-bit and 64-bit OSes. You'll need to compile a new *DE file for 32-bit and 64-bit separately and distribute the right file to right people. That applies even if you didn't have any ODBC drivers, ActiveX controls or API functions at all.

 

[DCrake]

Banana

Does this 32/64 bit senario occur for 2007? I have two laptops one with xp 32bit Access 2007

Plus a Windows 7 64 bit Access 2007 and have not come accross any issues as yet. Is this another reason not to upgrade?

 

[Banana]

DCrake -

No. 2007 is solidly 32-bit only.

Just to be clear here - there's two senses of how we can use "32-bit/64-bit" - WRT the OS or WRT the application. In your scenario, you are likely dealing with 64-bit OS but 32-bit Application (e.g. Office 2007). Because Office 2007 is still 32-bit, you don't have any issues other than possible quirks some people has reported with being unable to find some resources (e.g. looking for DLL in C:\Windows\system32\ when they actually want C:\Windows\SysWOW64\ on a 64-bit OS). So, 64-bit OS is largely irrelevant to Access 2007 & earlier.

With 2010, 32-bit is installed by default - to install 64-bit Office you have to manually open the right setup (there's no option in the installer to select a 64-bit) so for most part, your application will continue to function just fine in 32-bit Office 2010, even on a 64-bit OS just as it does for 32-bit 2007 on 64-bit OS. Game only changes when we're talking about 64-bit Office 2010 on 64-bit OS. Does that help?

 

[DCrake]

Yes it does, thanks