This database was created with the 64-bit version of Microsoft Access. Please open it with the 64-bit version of Microsoft Access.

[Ecc_9:10]

Hi everyone,

I'm an access newbie attempting to put a database in a trial environment and some users are getting the above error message when they try to open the file. I have saved it as an accde file for security.

Do I have to create a 32-bit version for them to open it and if so how would I do this?

 

[xavier.batlle]

Hi everyone,

I'm an access newbie attempting to put a database in a trial environment and some users are getting the above error message when they try to open the file. I have saved it as an accde file for security.

Do I have to create a 32-bit version for them to open it and if so how would I do this?

ACCDE databases can only be oppened with the same bitness of MS Access they were created. So 64 bit ACCDE can only be opened on computers with 64 bit Ms Access and 32 bit ACCDE can only be oppened on computers with 32 bit Ms Access.

 

[Gasman]

Have a look at Similar threads at the bottom of this post.

Unless you really need 64bit, I would reinstall and use 32bit, especially if the rest of your people are on 32bit.
You need to calculate how many on each, and go with the majority perhaps? I believe Access defaults now to 64 bit on install.

 

[The_Doc_Man]

I'm with Gasman. Unless there is a screaming need for 64-bit Office, you can install 32-bit Office and never know the difference. Both versions of Office will run cleanly in a 64-bit environment. (I've done so for about 20 years.) Having a "mixed bag" of bitness in a site that will share apps is going to be a painful process to manage.

Xavier's comment is true, but if the DB is in under trial, is it of type .ACCDE or .ACCDB? If the latter, a 64-bit version of Access should be able to run it IF it doesn't involve system API calls that might need certain address-pointer types. We would need to know more about the environment to know how best to proceed in that case.

 

[MarkK]

I have saved it as an accde file for security.

What kind of security? I mean, you declare yourself and Access newbie, and it sounds like you are in a development process, so just distribute .accdb files. Put functionality way out in front of security.

 

[gemma-the-husky]

Bitness is a problem. MS used to recommend 32,but, but now recommend 64bit, and install 64bit by default.

I think you are right to develop a accdb, but build it as an accde to distribute. However your code can't work in both 32bit and 64bit access. Therefore you have to select one, and make sure all your users use that version.

Code that calls external functions often needs to be written as 32bit or 64bit, and it's not always straightforward to make them 64bit, hence 32bit tends to be a simpler option.

You can't use a single version of Access to do both. You as developer, have to install the version you want, or have two computers. You might be able to use virtual machines, but I'm not sure.

 

[tvanstiphout]

> You might be able to use virtual machines, but I'm not sure.

That is exactly what I do. It assumes your computer has enough memory to run a VM. You can get away with 4 GB for the VM, but more is better.
Microsoft Hyper-V software is free to create a VM. You *do* need licenses for Windows and Office for that VM.

 

[gemma-the-husky]

if you issue a accdh, then you can include conditional code with compiler directives that says something like

#iff 64bit then
call 64 bit code statements
#else
call 32 bit code statements
#end if

it tests the environment first, and works properly in both environments.

however you can't produce an accde that makes the same choice at run time.
You have to have separate 32bit and 64bit databases, that build into 2 distinct accdes.

 

[isladogs]

You have to have separate 32bit and 64bit databases, that build into 2 distinct accdes.

Whilst you will need separate ACCDEs creating in 32-bit and 64-bit Access, you only need one development ACCDB file

You only need conditional compilation if any of your users are running A2007 or earlier.
See my article: https://www.isladogs.co.uk/32-64-conditional-compilation/index.html

Even if that is the case, I would then recommend using:

#If VBA7 Then
    'API code for A2010 or later (32-bit & 64-bit) - VBA7
#Else
    'API code for A2007 or earlier - VBA6
#End If

 

[gemma-the-husky]

Whilst you will need separate ACCDEs creating in 32-bit and 64-bit Access, you only need one development ACCDB file

You only need conditional compilation if any of your users are running A2007 or earlier.
See my article: https://www.isladogs.co.uk/32-64-conditional-compilation/index.html

Even if that is the case, I would then recommend using:

#If VBA7 Then
    'API code for A2010 or later (32-bit & 64-bit) - VBA7
#Else
    'API code for A2007 or earlier - VBA6
#End If

Doesn't it make a difference if all users have current version, but some 32bit and others 64bit?

 

[isladogs]

Doesn't it make a difference if all users have current version, but some 32bit and others 64bit?

No. Obviously you need different bitness ACCDEs, but the code would be identical for both 32-bit & 64-bit

 

[gemma-the-husky]

No. Obviously you need different bitness ACCDEs, but the code would be identical for both 32-bit & 64-bit

But don't you have to change the external functions in each case, for longptr, or whatever it is. You can't build the same code, can you?

 

[isladogs]

This is an extract from my article: https://www.isladogs.co.uk/32-64-conditional-compilation/
Particularly note item c)

a) Adding PtrSafe acts solely to tell Access the declarations are safe to use in VBA7 (32-bit or 64-bit).
If omitted, the declarations will not compile in 64-bit
Once PtrSafe is added to each API, the declarations will compile in 64-bit but, unless other changes are made, they may not work.
Of the 4 API statements above, the only one that requires no additional changes is GetSystemMetrics
b) Handles/pointers to memory locations require more space in 64-bit so a new LongLong datatype was created in VBA7 for this purpose.
However, LongLong ONLY works in 64-bit Access
c) To simplify working with APIs in different bitnesses, Microsoft also created a 'dummy' datatype LongPtr.
This resolves to LongLong in 64-bit and Long in 32-bit versions of Access using VBA7 (A2010 or later).