Possible to use a 64-bit database in Access 2010 32-bit?

[DaveCUK]

Looking at the subject line, I suspect I know the answer… :banghead:

When I bought Office 2010, the 64-bit sounded like the way to go. Bigger files, making use of the latest hardware, etc. Now I think I may have been wrong.

I have a very basic question.

I have Access 2010 64-bit. If I create a database using this, will it work on Access 2010 32-bit (and earlier versions such as 2007)? Simple question but I have just wasted an hour searching the Net for an answer…

I have already found that creating a package solution and trying to use it on a 32-bit OS doesn’t work (I was hoping it would if I used the 32-bit runtime. Worth a try as I had nothing to lose…).

TIA

 

[pr2-eugin]

Hello DaveCUK, Welcome to AWF..

It is possible to use 64-bit on an 32-bit version.. Just needs a small If check.. I use the following..

#If Win64 Then
   [COLOR=Green] 'Declare PtrSafe Function FunctionName Lib "kernel32" () As LongLong[/COLOR]
    Private Declare PtrSafe Function LoadLibrary Lib "kernel32" _
    Alias "LoadLibraryA" (ByVal lpLibFileName As String) As LongLong
    
    Private Declare PtrSafe Function FreeLibrary Lib "kernel32" _
    (ByVal hLibModule As Long) As LongLong
    
    Private Declare PtrSafe Function GetCurrentThreadId Lib "kernel32" () As LongLong
#Else
   [COLOR=Green] 'Declare PtrSafe Function FunctionName Lib "kernel32" () As Long[/COLOR]
    Private Declare PtrSafe Function LoadLibrary Lib "kernel32" _
    Alias "LoadLibraryA" (ByVal lpLibFileName As String) As Long
    
    Private Declare PtrSafe Function FreeLibrary Lib "kernel32" _
    (ByVal hLibModule As Long) As Long
    
    Private Declare PtrSafe Function GetCurrentThreadId Lib "kernel32" () As Long
#End If

Also any other library function that you use in your application..

OOPS !! Forgot to mention this would go in a Module.. If you have no module, create a new module and insert the above code, give the module a name, save and compile..

 

[DaveCUK]

Thanks for the quick and very helpful reply.

Re the package solution problem, am I correct in thinking that I cannot create a package using Access 64 that will work on a 32-bit OS (Win 7 Starter in this case)? I tried and got an error and so looked again in the package solution wizard to see if any friendly looking check boxes re running under 32-bit but alas, no. Is there a workaround of some sort? A hotfix perhaps?

 

[pr2-eugin]

I should be honest, I have not worked with Packages before.. So I am gonna say "Am sorry I do not know that"..

What error did you get while trying to open in the 32-bit machine? If you create an App from a 32 bit machine, I think this would not be a problem..

 

[pr2-eugin]

To explain more on the above post.. I have my local machine (development), and few other systems in my office on 32 bit Access, while our server runs 64 bit.. So I have to create two separate ACCDE versions, one from a 32 bit environment, and the other from a 64 bit environment.. I think this would apply for Packages as well.. But I am not sure..

 

[DaveCUK]

What error did you get while trying to open in the 32-bit machine? If you create an App from a 32 bit machine, I think this would not be a problem..

"The version of this file is not compatible with the version of Windows you're running". Given I was trying to run a 64-bit file on a 32-bit OS, I can understand that. Question is, is it possible to create a 32-bit package using 64-bit Access? My research would suggest not...

I know that if I had the 32-bit Access installed everything would probably be fine but to me it seems a backward step to uninstall the most up to date version (the 64-bit) and roll back to a previous one (the 32-bit which runs on an emulator on a 64-bit OS).. Just seems crazy. So much for backwards compatibility... Nice one Microsoft.

 

[Pat Hartman]

It isn't the most up to date and probably gets lets use and so fixes will be longer in coming. Bigger isn't necessarily better. Is it really better that your users can create million row spreadsheets? I don't think so.

You can uninstall the 64-bit version of Office and install the 32-bit version in its place. The 64-bit version gives you nothing - Except a headache with distribution. In addition to the distribution issues, I think you also loose any ActiveX controls such as the TreeView and ListView (or maybe it's A2013 where you loose those - I'm confused).

We didn't feel the pain of going from 16-bit Access to 32-bit Access because the 32-bit Access simply didn't read the 16-bit database (A2.0). MS ultimately released an add-in that allowed it. But that only allowed you to update data or read the database for conversion. I think we have the same situation here. Changing the register size is simply too big a bar to cross since it impacts too much code.

 

[DaveCUK]

Ok, I give up. So I need to uninstall the 64-bit version of Office 2010 and install the 32-bit one. Sounds easy...

I am concerned about the product key so is there a right way and a wrong way to do this?

I guess I uninstall the 64-bit one using the normal Windows uninstall (from the control panel) and then install using the setup file that came with the 32-bit version? I know this is a very basic question but if there is a better way then I would rather look silly now than spend all afternoon doing it and setting up all my email accounts and other settings again...

Thanks again in advance

 

[Pat Hartman]

I haven't had to do it but that is my understanding of how it works. Your product key is good for both versions.

 

[IBadri]

Hello DaveCUK, Welcome to AWF..

It is possible to use 64-bit on an 32-bit version.. Just needs a small If check.. I use the following..

#If Win64 Then
   [COLOR=Green] 'Declare PtrSafe Function FunctionName Lib "kernel32" () As LongLong[/COLOR]
    Private Declare PtrSafe Function LoadLibrary Lib "kernel32" _
    Alias "LoadLibraryA" (ByVal lpLibFileName As String) As LongLong
    
    Private Declare PtrSafe Function FreeLibrary Lib "kernel32" _
    (ByVal hLibModule As Long) As LongLong
    
    Private Declare PtrSafe Function GetCurrentThreadId Lib "kernel32" () As LongLong
#Else
   [COLOR=Green] 'Declare PtrSafe Function FunctionName Lib "kernel32" () As Long[/COLOR]
    Private Declare PtrSafe Function LoadLibrary Lib "kernel32" _
    Alias "LoadLibraryA" (ByVal lpLibFileName As String) As Long
    
    Private Declare PtrSafe Function FreeLibrary Lib "kernel32" _
    (ByVal hLibModule As Long) As Long
    
    Private Declare PtrSafe Function GetCurrentThreadId Lib "kernel32" () As Long
#End If

Also any other library function that you use in your application..

OOPS !! Forgot to mention this would go in a Module.. If you have no module, create a new module and insert the above code, give the module a name, save and compile..

Thanks a lot Mr. Paul,

It's solved my problem by creating the module above on the machine running a 32 bit, and compile it.
After compiling. protect and save the file as accde, etc...