[AccessD] 32->64 bit Conversion
stuart at lexacorp.com.pg
Tue Nov 9 17:28:25 CST 2021
Susan is mistaken. The issue here is solely one of what version of Office your clients are
using. Full stop.
If any client machine is using 64bit Office, your application needs to be upgraded to make it
compatible with their installation. (Once you have done so, it will still work on their machines
using 32bit Office)
If your application uses API functions or calls to any external OCX or DLL, and your client
uses 64 bit Office, your application HAS to be written to work with 64bit Office.
That means that PTRSAFE and LONGPTR are essential - not using them will break your
application since an Access application running on 64bit Office can't make calls to 32bit
But in a way, "memory" is the issue :)
A 64bit application uses 64 bit memory addressing. That's the whole reason why you need
to use LONGPTR for any reference to a handle, structure or other memory location.
The Access compiler will make such references 64 bit or 32 bit depending on what version it
is running on (re-compiling on-the-fly if required)
On 9 Nov 2021 at 17:50, Arthur Fuller wrote:
> Ok Susan. why waste more time converting to something without
> benefits? Good point.
> On Tue, Nov 9, 2021 at 5:40 PM Susan Harkins <ssharkins at gmail.com>
> > Arthur, the only reason to move to 64 is a memory issue. If it's
> > necessary do it. If not, don't.
> > Susan H.
More information about the AccessD