[AccessD] 32->64 bit Conversion

[Stuart McLachlan]

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 
DLLs. 

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>
> wrote:
> 
> > Arthur, the only reason to move to 64 is a memory issue. If it's
> > necessary do it. If not, don't.
> >
> > Susan H.
> >